Greetings. I pulled the latest master and noticed that contrib has been moved into a separate repository. I also cloned this contrib repository, but can not find the file scripts/ditaa.jar in the repo. In fact, there is no directory scripts in the repo. The documentation in the latest master states that Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now packaged into the org-contrib repository. How should I proceed? Should I build this separately https://github.com/stathissideris/ditaa or will it still be included into contrib? Have fun and stay safe! Jarmo
On Monday, 10 May 2021 at 14:28, Jarmo Hurri wrote:
> I pulled the latest master and noticed that contrib has been moved into
> a separate repository. I also cloned this contrib repository, but can
> not find the file
>
> scripts/ditaa.jar
>
> in the repo. In fact, there is no directory scripts in the repo.
Bastien mentioned to me, off list, that he was going to move ditaa.jar
to Worg, specifically to worg/code/scripts, but this does not seem to
have taken place (yet).
FYI, Debian has the ditaa package which includes ditaa.jar.
--
: Eric S Fraga via Emacs 28.0.50, Org release_9.4.5-395-g82fbdd
On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote: > I pulled the latest master and noticed that contrib has been moved into > a separate repository. I also cloned this contrib repository, but can > not find the file > > scripts/ditaa.jar > > in the repo. In fact, there is no directory scripts in the repo. I actually never considered this might be packaged with Org. I always thought I had to install it separately, like my Latex distribution or PlantUML. ------------------------------------------------------------------ Russell Adams RLAdams@AdamsInfoServ.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
[-- Attachment #1: Type: text/plain, Size: 742 bytes --] Russell Adams <RLAdams@AdamsInfoServ.Com> writes: > On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote: >> I pulled the latest master and noticed that contrib has been moved into >> a separate repository. I also cloned this contrib repository, but can >> not find the file >> >> scripts/ditaa.jar >> >> in the repo. In fact, there is no directory scripts in the repo. > > I actually never considered this might be packaged with Org. I always > thought I had to install it separately, like my Latex distribution or > PlantUML. Bundling this makes ditaa code blocks just work. Otherwise they won’t work on every org-install. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
Jarmo Hurri <jarmo.hurri@iki.fi> writes: > Greetings. > > I pulled the latest master and noticed that contrib has been moved into > a separate repository. I also cloned this contrib repository, but can > not find the file > > scripts/ditaa.jar > > in the repo. In fact, there is no directory scripts in the repo. > > The documentation in the latest master states that > > Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now > packaged into the org-contrib repository. > > How should I proceed? Should I build this separately > > https://github.com/stathissideris/ditaa You don't need to build it: it's available in the release area https://github.com/stathissideris/ditaa/releases > > or will it still be included into contrib? In general, I think it's a better idea to point to the canonical sources and document how to integrate it into Org mode, than bundle things like that, but I have no idea how things are going to go. I'm sure there will be some problems that will need fixing one way or another. -- Nick "There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors." -Martin Fowler
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
>
>> On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote:
>>> I pulled the latest master and noticed that contrib has been moved into
>>> a separate repository. I also cloned this contrib repository, but can
>>> not find the file
>>>
>>> scripts/ditaa.jar
>>>
>>> in the repo. In fact, there is no directory scripts in the repo.
>>
>> I actually never considered this might be packaged with Org. I always
>> thought I had to install it separately, like my Latex distribution or
>> PlantUML.
>
> Bundling this makes ditaa code blocks just work. Otherwise they won’t
> work on every org-install.
The user still needs a Java runtime installed on his/her compute, so
bundling ditaa.jar gives no guarantee at all that ditaa blocks will just
work on every org-install.
Instead a less informaed user, not used to run java programs, might be
left with a not working application that fails silently or to the user
incomprehensible error message.
Better to point user to ditaa's sources/releases and inform it is
optional with org. That way non-informed user will have to install java
and ditaa and will at least have an idea where to look when things go wrong.
If org-mode wants to support ditaa, it is a requirement to inform the user how to
get the software and install it. Moving into into a separate repository without
appropriately telling the user introduces the problem that users will miss out
on free software that they would otherwise have used. Using org should not be made
more difficult than it already is.
> Sent: Tuesday, May 11, 2021 at 8:49 AM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> Cc: emacs-orgmode@gnu.org
> Subject: Re: The fate of ditaa.jar (9.4.5.)
>
> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
> > Russell Adams <RLAdams@AdamsInfoServ.Com> writes:
> >
> >> On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote:
> >>> I pulled the latest master and noticed that contrib has been moved into
> >>> a separate repository. I also cloned this contrib repository, but can
> >>> not find the file
> >>>
> >>> scripts/ditaa.jar
> >>>
> >>> in the repo. In fact, there is no directory scripts in the repo.
> >>
> >> I actually never considered this might be packaged with Org. I always
> >> thought I had to install it separately, like my Latex distribution or
> >> PlantUML.
> >
> > Bundling this makes ditaa code blocks just work. Otherwise they won’t
> > work on every org-install.
>
> The user still needs a Java runtime installed on his/her compute, so
> bundling ditaa.jar gives no guarantee at all that ditaa blocks will just
> work on every org-install.
>
> Instead a less informaed user, not used to run java programs, might be
> left with a not working application that fails silently or to the user
> incomprehensible error message.
>
> Better to point user to ditaa's sources/releases and inform it is
> optional with org. That way non-informed user will have to install java
> and ditaa and will at least have an idea where to look when things go wrong.
>
>
If having the source is not as easy as getting a link that is dependable,
then it got to be bundled. I rather use a version that works than nothing
at all. I have used ditaa in org for the documentation of texinfo.
> Sent: Tuesday, May 11, 2021 at 6:41 AM
> From: "Nick Dokos" <ndokos@gmail.com>
> To: emacs-orgmode@gnu.org
> Subject: Re: The fate of ditaa.jar (9.4.5.)
>
> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
>
> > Greetings.
> >
> > I pulled the latest master and noticed that contrib has been moved into
> > a separate repository. I also cloned this contrib repository, but can
> > not find the file
> >
> > scripts/ditaa.jar
> >
> > in the repo. In fact, there is no directory scripts in the repo.
> >
> > The documentation in the latest master states that
> >
> > Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now
> > packaged into the org-contrib repository.
> >
> > How should I proceed? Should I build this separately
> >
> > https://github.com/stathissideris/ditaa
>
> You don't need to build it: it's available in the release area
>
> https://github.com/stathissideris/ditaa/releases
>
> >
> > or will it still be included into contrib?
>
> In general, I think it's a better idea to point to the canonical sources
> and document how to integrate it into Org mode, than bundle things like
> that, but I have no idea how things are going to go. I'm sure there will
> be some problems that will need fixing one way or another.
>
> --
> Nick
>
> "There are only two hard problems in computer science: cache
> invalidation, naming things, and off-by-one errors." -Martin Fowler
>
>
>
Nick Dokos <ndokos@gmail.com> writes:
> Jarmo Hurri <jarmo.hurri@iki.fi> writes:
>
>> Greetings.
>>
>> I pulled the latest master and noticed that contrib has been moved into
>> a separate repository. I also cloned this contrib repository, but can
>> not find the file
>>
>> scripts/ditaa.jar
>>
>> in the repo. In fact, there is no directory scripts in the repo.
>>
>> The documentation in the latest master states that
>>
>> Stathis Sideris wrote the ‘ditaa.jar’ ASCII to PNG converter that is now
>> packaged into the org-contrib repository.
>>
>> How should I proceed? Should I build this separately
>>
>> https://github.com/stathissideris/ditaa
>
> You don't need to build it: it's available in the release area
>
> https://github.com/stathissideris/ditaa/releases
>
>>
>> or will it still be included into contrib?
>
> In general, I think it's a better idea to point to the canonical sources
> and document how to integrate it into Org mode, than bundle things like
> that, but I have no idea how things are going to go. I'm sure there will
> be some problems that will need fixing one way or another.
I agree. As pointed out already, just bundling the jar file is not
sufficient as you need a java runtime as well. If we bundle it, we also
need to ensure it is updated if/when new jar versions are released.
Better to clearly document where to get the dependencies and point to
the appropriate installation instructions.
I think we also need to keep in mind that we are currently in a bit of a
transition stage with the move to using ELPA and non-gnu ELPA. There
will be teething problems needing to be worked through both before and
after the transition.
--
Tim Cross
[-- Attachment #1: Type: text/plain, Size: 982 bytes --] Tim Cross <theophilusx@gmail.com> writes: > I agree. As pointed out already, just bundling the jar file is not > sufficient as you need a java runtime as well. Java is available in my distribution, ditaa is not. Removing ditaa from org means that I have to do manual installation and configuration, while with ditaa bundled, org-mode can simply note that I need java installed. > If we bundle it, we also need to ensure it is updated if/when new jar > versions are released. We can do that, but we don’t have to. As long as the bundled jar works, it is much better than no jar. And users can use newer version as they like by changing the jar-path. Note that this isn’t about security, since even if an old version of ditaa should turn out to be vulnerable, this would still be less dangerous than a shell-block. Therefore old versions of ditaa are completely fine. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
> Sent: Tuesday, May 11, 2021 at 6:35 PM > From: "Dr. Arne Babenhauserheide" <arne_bab@web.de> > To: "Tim Cross" <theophilusx@gmail.com> > Cc: emacs-orgmode@gnu.org > Subject: Re: The fate of ditaa.jar (9.4.5.) > > > Tim Cross <theophilusx@gmail.com> writes: > > I agree. As pointed out already, just bundling the jar file is not > > sufficient as you need a java runtime as well. > > Java is available in my distribution, ditaa is not. Removing ditaa from > org means that I have to do manual installation and configuration, while > with ditaa bundled, org-mode can simply note that I need java installed. > > > If we bundle it, we also need to ensure it is updated if/when new jar > > versions are released. > > We can do that, but we don’t have to. As long as the bundled jar works, > it is much better than no jar. And users can use newer version as they > like by changing the jar-path. A jar that works would be good as initial setup, then people can change that as they wish. > Note that this isn’t about security, since even if an old version of > ditaa should turn out to be vulnerable, this would still be less > dangerous than a shell-block. Therefore old versions of ditaa are > completely fine. > > Best wishes, > Arne > -- > Unpolitisch sein > heißt politisch sein > ohne es zu merken >
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes: > [[PGP Signed Part:Undecided]] > > Tim Cross <theophilusx@gmail.com> writes: >> I agree. As pointed out already, just bundling the jar file is not >> sufficient as you need a java runtime as well. > > Java is available in my distribution, ditaa is not. Removing ditaa from > org means that I have to do manual installation and configuration, while > with ditaa bundled, org-mode can simply note that I need java installed. > I get that. However, this is of course not the case for many users (Mac, Windows). Having to install additional software to realise org functionality is normal for much of org-mode. In fact, I had to install ditta when I first used it because it wasn't bundled. That was not an issue and no surprise given I also had to install textlive, plantuml, graphviz, taskjuggler, ledger, sqlite and many other things. I understand the convenience for users argument. However, I think we also need to consider the maintenance overheads and consistency aspects as well (including dealing with bug reports when it doesn't work). >> If we bundle it, we also need to ensure it is updated if/when new jar >> versions are released. > > We can do that, but we don’t have to. As long as the bundled jar works, > it is much better than no jar. And users can use newer version as they > like by changing the jar-path. > > Note that this isn’t about security, since even if an old version of > ditaa should turn out to be vulnerable, this would still be less > dangerous than a shell-block. Therefore old versions of ditaa are > completely fine. > My thoughts were more about bugs and confusing deprecation warnings which can arise when using an older jar file with a more recent jre. Ultimately, it will fall to whoever steps up to maintain ditta support to decide. -- Tim Cross
Tim Cross <theophilusx@gmail.com> writes:
> I also had to install textlive, plantuml, graphviz, taskjuggler,
> ledger, sqlite and many other things.
Perhaps it would be good to make a table of
| software | needed for | package name | download page |
and/or prompt users when an action requiring another executable is
undertaken if it isn't found.
--
Timothy
Christopher Dimech <dimech@gmx.com> writes: > If org-mode wants to support ditaa, it is a requirement to inform the user how to > get the software and install it. Moving into into a separate repository without > appropriately telling the user introduces the problem that users will miss out > on free software that they would otherwise have used. Using org should not be made > more difficult than it already is. > Another problem I didn't mention in previous replay, is that user can have wrong (outdated) version of Java installed on his/her machine which might not be compatible with ditaa version org mode ships, which may introduce further questions and problems. IMO I think it is better to leave out 3rd party applications and let users install those on their own. >> Sent: Tuesday, May 11, 2021 at 8:49 AM >> From: "Arthur Miller" <arthur.miller@live.com> >> To: "Dr. Arne Babenhauserheide" <arne_bab@web.de> >> Cc: emacs-orgmode@gnu.org >> Subject: Re: The fate of ditaa.jar (9.4.5.) >> >> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes: >> >> > Russell Adams <RLAdams@AdamsInfoServ.Com> writes: >> > >> >> On Mon, May 10, 2021 at 02:28:57PM +0300, Jarmo Hurri wrote: >> >>> I pulled the latest master and noticed that contrib has been moved into >> >>> a separate repository. I also cloned this contrib repository, but can >> >>> not find the file >> >>> >> >>> scripts/ditaa.jar >> >>> >> >>> in the repo. In fact, there is no directory scripts in the repo. >> >> >> >> I actually never considered this might be packaged with Org. I always >> >> thought I had to install it separately, like my Latex distribution or >> >> PlantUML. >> > >> > Bundling this makes ditaa code blocks just work. Otherwise they won’t >> > work on every org-install. >> >> The user still needs a Java runtime installed on his/her compute, so >> bundling ditaa.jar gives no guarantee at all that ditaa blocks will just >> work on every org-install. >> >> Instead a less informaed user, not used to run java programs, might be >> left with a not working application that fails silently or to the user >> incomprehensible error message. >> >> Better to point user to ditaa's sources/releases and inform it is >> optional with org. That way non-informed user will have to install java >> and ditaa and will at least have an idea where to look when things go wrong. >> >>
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> Java is available in my distribution, ditaa is not. Removing ditaa from
> org means that I have to do manual installation and configuration, while
> with ditaa bundled, org-mode can simply note that I need java installed.
>
>> If we bundle it, we also need to ensure it is updated if/when new jar
>> versions are released.
>
> We can do that, but we don’t have to. As long as the bundled jar works,
> it is much better than no jar.
Depending on what users have on their machines it may not work on their
machine. The bundled jar might ask for a version of Java runtime that
users does not have. There is no guarantee that every distribution comes
with java bundled either. For you it maybe works, for someone else it
might generate 1001 question and confusion when things don't work.
TEC <tecosaur@gmail.com> writes: > Tim Cross <theophilusx@gmail.com> writes: > >> I also had to install textlive, plantuml, graphviz, taskjuggler, >> ledger, sqlite and many other things. > > Perhaps it would be good to make a table of > > | software | needed for | package name | download page | Maybe there could be a hash table where one can register a function with a software, similar to how autoload works. but instead of specifying file where function is found, we could specify a sotware/package name and a link to download/main page? Maybe function level is too granular, maybe per feature level? > and/or prompt users when an action requiring another executable is > undertaken if it isn't found. > I think it's a good idea. A minor mode that can be turned off for experienced users but on by default and maybe with knowledge where to find the required software, i.e. a link that Emacs can open in default a web browser for the user. Ultimate would be to offer a download, but considering all the distros and possible dead links, probably better to go just for download or main page.
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --] Arthur Miller <arthur.miller@live.com> writes: > Christopher Dimech <dimech@gmx.com> writes: > >> If org-mode wants to support ditaa, it is a requirement to inform the user how to >> get the software and install it. Moving into into a separate repository without >> appropriately telling the user introduces the problem that users will miss out >> on free software that they would otherwise have used. Using org should not be made >> more difficult than it already is. >> > Another problem I didn't mention in previous replay, is that user can > have wrong (outdated) version of Java installed on his/her machine which > might not be compatible with ditaa version org mode ships, which may > introduce further questions and problems. IMO I think it is better to > leave out 3rd party applications and let users install those on their > own. The old version should just keep working. It requires a Java older than Java 8, and Java 8 is available everywhere. For the new releases that is less clear, since ditaa is adding Clojure. I would bundle the old version to keep old documents working (I do not want org-mode to be volatile software[1] that breaks existing documents with an update), but notify the user that a new version exists. [1]: https://stevelosh.com/blog/2012/04/volatile-software/ Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
TEC <tecosaur@gmail.com> writes:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> I also had to install textlive, plantuml, graphviz, taskjuggler,
>> ledger, sqlite and many other things.
>
> Perhaps it would be good to make a table of
>
> | software | needed for | package name | download page |
>
> and/or prompt users when an action requiring another executable is
> undertaken if it isn't found.
Useful additional documentation, assuming it can be maintained, is
rarely a bad idea. A table on worg (with maybe a link in the manual)
which lists all the org (and contrib) features, external dependencies
and link to canonical source would probably be a good idea.
I find it hard to remember how I worked out all the dependencies as I
adopted org as it was so long ago and I was already a heavy user of
many of the tools/dependencies of org. This makes it challenging to
appreciate how hard it can be for someone knew to org. On the other
hand, if we make it overly easy/automatic, we run the risk of
disempowering the user and making them more dependent on assistance from
others. Finding the right balance between informative and concise is a
challenge. If we provide too much information, it can be overwhelming,
too little and it can be confusing. I find it harder to write good
documentation than good code!
--
Tim Cross
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes: > Arthur Miller <arthur.miller@live.com> writes: > >> Christopher Dimech <dimech@gmx.com> writes: >> >>> If org-mode wants to support ditaa, it is a requirement to inform the user how to >>> get the software and install it. Moving into into a separate repository without >>> appropriately telling the user introduces the problem that users will miss out >>> on free software that they would otherwise have used. Using org should not be made >>> more difficult than it already is. >>> >> Another problem I didn't mention in previous replay, is that user can >> have wrong (outdated) version of Java installed on his/her machine which >> might not be compatible with ditaa version org mode ships, which may >> introduce further questions and problems. IMO I think it is better to >> leave out 3rd party applications and let users install those on their >> own. > > The old version should just keep working. It requires a Java older than > Java 8, and Java 8 is available everywhere. I don't think that would be the case. Java is considered unsafe software so I wouldn't rely on older versions being pre-installed and avialable everywhere. > I would bundle the old version to keep old documents working (I do not > want org-mode to be volatile software[1] that breaks existing documents > with an update), but notify the user that a new version exists. Since you already have Java and ditaa installed on your computer, your older documents won't get broken. By the way, how difficult is to download one file from the internet (ditaa.jar) if you are an user?
> I find it harder to write good
> documentation than good code!
Yes indeed, takes so much more time than to just write the code :).
[-- Attachment #1: Type: text/plain, Size: 1588 bytes --] Arthur Miller <arthur.miller@live.com> writes: > I don't think that would be the case. Java is considered unsafe software > so I wouldn't rely on older versions being pre-installed and avialable everywhere. Java is not considered unsafe software — not any more than any interpreted language. What’s unsafe are Java applets, but those are not what ditaa uses. >> I would bundle the old version to keep old documents working (I do not >> want org-mode to be volatile software[1] that breaks existing documents >> with an update), but notify the user that a new version exists. > > Since you already have Java and ditaa installed on your computer, your > older documents won't get broken. I have Java, but not ditaa, because Java is packaged in my distribution and ditaa is not. My build pipelines use ditaa as shipped with org-mode. Different from plantuml, there is no ditaa-runner to install as application. So unbundling ditaa breaks my documents when updating org-mode. The same for everyone else who used a standard ditaa-setup with org-mode. > By the way, how difficult is to download one file from the internet > (ditaa.jar) if you are an user? That’s not the point. The point is that every single user with a ditaa block has to do it. Ask the other way round: What is the benefit of removing ditaa from org? If you want to force most current org-ditaa users to unbreak their setup after update, there should be a significant tangible benefit. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
On Wed, May 12, 2021 at 11:41:48AM +0200, Dr. Arne Babenhauserheide wrote: > I have Java, but not ditaa, because Java is packaged in my distribution > and ditaa is not. My build pipelines use ditaa as shipped with > org-mode. My opinion is that Org has integration for many external tools, but doesn't ship them. I don't think Org should be shipping anything that isn't Org's own code due to maintainer overhead, potential legal/license issues, and inconsistency across tools. We don't ship Latex distributions or gnuplot either. > So unbundling ditaa breaks my documents when updating org-mode. The same > for everyone else who used a standard ditaa-setup with org-mode. I think it's a reasonable request to make of an end user that if you want to use Org's integration with the tool, you ensure the tool is installed first. If your Linux distribution doesn't provide a package for ditaa, file a bug report or a feature request with them. Alternatively you can install it yourself as it's just one .jar file. Perhaps Org should show a better error message if ditaa isn't found. > Ask the other way round: What is the benefit of removing ditaa from org? > If you want to force most current org-ditaa users to unbreak their setup > after update, there should be a significant tangible benefit. Org's codebase is always undergoing change and right now there's a significant cleanup effort going on to separate contrib out of core. I expect removing ditaa was part of that. I defer here to the wisdom of the maintainers that there is benefit to reorganizing the code base, even if it's just to simplify their job as maintainers. I respect that it's causing you some personal inconvenience, however it's not a major breakage. It should be simple to resolve by installing locally. ------------------------------------------------------------------ Russell Adams RLAdams@AdamsInfoServ.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3
Greetings.
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> Arthur Miller <arthur.miller@live.com> writes:
>
>> By the way, how difficult is to download one file from the internet
>> (ditaa.jar) if you are an user?
>
> That’s not the point. The point is that every single user with a ditaa
> block has to do it.
>
> Ask the other way round: What is the benefit of removing ditaa from
> org? If you want to force most current org-ditaa users to unbreak
> their setup after update, there should be a significant tangible
> benefit.
I agree.
One thing I like about org is that most things work out of the box.
While I can download/install/compile/whatever ditaa.jar, having to do so
adds a step. This extra step will result in fewer people using the
combination of org and ditaa. I do not think that is a good direction.
Comparing ditaa to latex/java/C/such does not feel fair, since distros
support standard software, and ditaa does not seem to qualify. But this
is an assumption. At least my distro does not support ditaa in a
package.
Just my opinion. As always, happy to leave the final decision to the
wise ones.
Have fun and stay safe!
Jarmo
Jarmo Hurri <jarmo.hurri@iki.fi> writes: > Greetings. > > "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes: > >> Arthur Miller <arthur.miller@live.com> writes: >> >>> By the way, how difficult is to download one file from the internet >>> (ditaa.jar) if you are an user? >> >> That’s not the point. The point is that every single user with a ditaa >> block has to do it. >> >> Ask the other way round: What is the benefit of removing ditaa from >> org? If you want to force most current org-ditaa users to unbreak >> their setup after update, there should be a significant tangible >> benefit. > > I agree. > > One thing I like about org is that most things work out of the box. If bundled ditaa is not compatible with jre installed on users computer, or there is no jre installed, and user is not a programmer or used to Java, how many steps it adds to such a user to sort out why org does not work for him/her "out of the box"? Just to save some experienced user an extra step, that probably does not even affect them since they already have java and ditaa on their computers. > Comparing ditaa to latex/java/C/such does not feel fair, since distros Ditaa requires jre to work. Should org distribute a version of jre too to make it sure it works on user computer "out of the box"?
[-- Attachment #1: Type: text/plain, Size: 2100 bytes --] Arthur Miller <arthur.miller@live.com> writes: > Jarmo Hurri <jarmo.hurri@iki.fi> writes: > >> Greetings. >> >> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes: >> >>> Arthur Miller <arthur.miller@live.com> writes: >>> >>>> By the way, how difficult is to download one file from the internet >>>> (ditaa.jar) if you are an user? >>> >>> That’s not the point. The point is that every single user with a ditaa >>> block has to do it. >>> >>> Ask the other way round: What is the benefit of removing ditaa from >>> org? If you want to force most current org-ditaa users to unbreak >>> their setup after update, there should be a significant tangible >>> benefit. >> >> I agree. >> >> One thing I like about org is that most things work out of the box. > > If bundled ditaa is not compatible with jre installed on users > computer, or there is no jre installed, and user is not a programmer or > used to Java, how many steps it adds to such a user to sort out why org > does not work for him/her "out of the box"? Just to save some experienced > user an extra step, that probably does not even affect them since they > already have java and ditaa on their computers. The difference is not about the difference between experienced or beginner. The difference is that „use your package manager to get Java“ or „get openjdk“ is an operation that only uses standard installation processes. „Get this jar-file from somewhere and drop it somewhere and then change this configuration to point to it“ is not a standard installation action. If Java is missing, org can simply report „no java found, please install openjdk from <linux: your package manager | windows/macos: https://adoptopenjdk.net/installation.html>“ and the user can install it like any other software. This is not the case with ditaa. Ditaa is no standard application with installer/setup/…, but a jar-file. And removing it breaks existing setups when org-mode is updated. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes: > Arthur Miller <arthur.miller@live.com> writes: > >> Jarmo Hurri <jarmo.hurri@iki.fi> writes: >> >>> Greetings. >>> >>> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes: >>> >>>> Arthur Miller <arthur.miller@live.com> writes: >>>> >>>>> By the way, how difficult is to download one file from the internet >>>>> (ditaa.jar) if you are an user? >>>> >>>> That’s not the point. The point is that every single user with a ditaa >>>> block has to do it. >>>> >>>> Ask the other way round: What is the benefit of removing ditaa from >>>> org? If you want to force most current org-ditaa users to unbreak >>>> their setup after update, there should be a significant tangible >>>> benefit. >>> >>> I agree. >>> >>> One thing I like about org is that most things work out of the box. >> >> If bundled ditaa is not compatible with jre installed on users >> computer, or there is no jre installed, and user is not a programmer or >> used to Java, how many steps it adds to such a user to sort out why org >> does not work for him/her "out of the box"? Just to save some experienced >> user an extra step, that probably does not even affect them since they >> already have java and ditaa on their computers. > > The difference is not about the difference between experienced or > beginner. The difference is that „use your package manager to get Java“ > or „get openjdk“ is an operation that only uses standard installation > processes. > > „Get this jar-file from somewhere and drop it somewhere and then change > this configuration to point to it“ is not a standard installation > action. > > If Java is missing, org can simply report „no java found, please install > openjdk from <linux: your package manager | windows/macos: > https://adoptopenjdk.net/installation.html>“ and the user can install it > like any other software. So can org also say: "ditaa is missing, please install from the link ... " :-) > This is not the case with ditaa. Ditaa is no standard application with > installer/setup/…, but a jar-file. Exactly, so it is enough to just download a single file and point your org to it with one `setq' in your init file. So it does not need a pacakge managmenet on os level. However, Org could also simply say: use another distro that has ditaa in it's repository, such as Arch Linuz (in AUR).
[-- Attachment #1: Type: text/plain, Size: 655 bytes --] Arthur Miller <arthur.miller@live.com> writes: > Exactly, so it is enough to just download a single file and point your > org to it with one `setq' in your init file. So it does not need a > pacakge managmenet on os level. Package management is how users should install software. Otherwise you quickly reach the point where they blindly curl and run untrusted shell-scripts from shady websites. > However, Org could also simply say: use another distro that has ditaa in > it's repository, such as Arch Linuz (in AUR). That would be openly hostile. Best wishes, Arne -- Unpolitisch sein heißt politisch sein ohne es zu merken [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 1125 bytes --]
> Sent: Friday, May 14, 2021 at 5:30 PM > From: "Dr. Arne Babenhauserheide" <arne_bab@web.de> > To: "Arthur Miller" <arthur.miller@live.com> > Cc: "Jarmo Hurri" <jarmo.hurri@iki.fi>, emacs-orgmode@gnu.org > Subject: Re: The fate of ditaa.jar (9.4.5.) > > > Arthur Miller <arthur.miller@live.com> writes: > > > Exactly, so it is enough to just download a single file and point your > > org to it with one `setq' in your init file. So it does not need a > > pacakge managmenet on os level. > > Package management is how users should install software. Otherwise you > quickly reach the point where they blindly curl and run untrusted > shell-scripts from shady websites. I agree with the assessment regarding shady websites. > > However, Org could also simply say: use another distro that has ditaa in > > it's repository, such as Arch Linuz (in AUR). > > That would be openly hostile. If there exists the serious problem of not finding ditaa, then ditaa should be provided. For the rest there exist no problem and users can easily install from their Package Manager. You can't brush off a boyfriend and expect him to do you a favor using Free Software by telling him to use another distro. ;) > Best wishes, > Arne > -- > Unpolitisch sein > heißt politisch sein > ohne es zu merken >
Christopher Dimech <dimech@gmx.com> writes: >> Sent: Friday, May 14, 2021 at 5:30 PM >> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de> >> To: "Arthur Miller" <arthur.miller@live.com> >> Cc: "Jarmo Hurri" <jarmo.hurri@iki.fi>, emacs-orgmode@gnu.org >> Subject: Re: The fate of ditaa.jar (9.4.5.) >> >> >> Arthur Miller <arthur.miller@live.com> writes: >> >> > Exactly, so it is enough to just download a single file and point your >> > org to it with one `setq' in your init file. So it does not need a >> > pacakge managmenet on os level. >> >> Package management is how users should install software. Otherwise you >> quickly reach the point where they blindly curl and run untrusted >> shell-scripts from shady websites. > > I agree with the assessment regarding shady websites. > >> > However, Org could also simply say: use another distro that has ditaa in >> > it's repository, such as Arch Linuz (in AUR). >> >> That would be openly hostile. No is not. There are so many distributions that are half-done, unmaintained, etc. By the way, if your distro does not have a package for ditaa, then you might maybe consider doing a community service and provide a package script for your distro? I guess your distro have some way for users to contribute a package? > If there exists the serious problem of not finding ditaa, then ditaa should be provided. > For the rest there exist no problem and users can easily install from their Package Manager. > > You can't brush off a boyfriend and expect him to do you a favor using Free Software > by telling him to use another distro. ;) > :-) It is just the usual one: "you deserve a better one ...."
> Sent: Friday, May 14, 2021 at 11:23 PM
> From: "Arthur Miller" <arthur.miller@live.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Dr. Arne Babenhauserheide" <arne_bab@web.de>, "Jarmo Hurri" <jarmo.hurri@iki.fi>, emacs-orgmode@gnu.org
> Subject: Re: The fate of ditaa.jar (9.4.5.)
>
> Christopher Dimech <dimech@gmx.com> writes:
>
> >> Sent: Friday, May 14, 2021 at 5:30 PM
> >> From: "Dr. Arne Babenhauserheide" <arne_bab@web.de>
> >> To: "Arthur Miller" <arthur.miller@live.com>
> >> Cc: "Jarmo Hurri" <jarmo.hurri@iki.fi>, emacs-orgmode@gnu.org
> >> Subject: Re: The fate of ditaa.jar (9.4.5.)
> >>
> >>
> >> Arthur Miller <arthur.miller@live.com> writes:
> >>
> >> > Exactly, so it is enough to just download a single file and point your
> >> > org to it with one `setq' in your init file. So it does not need a
> >> > pacakge managmenet on os level.
> >>
> >> Package management is how users should install software. Otherwise you
> >> quickly reach the point where they blindly curl and run untrusted
> >> shell-scripts from shady websites.
> >
> > I agree with the assessment regarding shady websites.
> >
> >> > However, Org could also simply say: use another distro that has ditaa in
> >> > it's repository, such as Arch Linuz (in AUR).
> >>
> >> That would be openly hostile.
>
> No is not. There are so many distributions that are half-done,
> unmaintained, etc. By the way, if your distro does not have a package
> for ditaa, then you might maybe consider doing a community service and
> provide a package script for your distro? I guess your distro have some
> way for users to contribute a package?
>
> > If there exists the serious problem of not finding ditaa, then ditaa should be provided.
> > For the rest there exist no problem and users can easily install from their Package Manager.
> >
> > You can't brush off a boyfriend and expect him to do you a favor using Free Software
> > by telling him to use another distro. ;)
> >
>
> :-) It is just the usual one: "you deserve a better one ...."
That would be true if you got a crappy one. :)
And perhaps maintain the table in elpa?
On 5/11/21 7:52 AM, TEC wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> I also had to install textlive, plantuml, graphviz, taskjuggler,
>> ledger, sqlite and many other things.
> Perhaps it would be good to make a table of
>
> | software | needed for | package name | download page |
>
> and/or prompt users when an action requiring another executable is
> undertaken if it isn't found.
>
> --
> Timothy
>
Hi Jarmo, Jarmo Hurri <jarmo.hurri@iki.fi> writes: > I pulled the latest master and noticed that contrib has been moved into > a separate repository. I also cloned this contrib repository, but can > not find the file > > scripts/ditaa.jar It still lives here: https://orgmode.org/worg/code/scripts/ (I forgot to push the files on Worg at first, but this is fixed.) I also mentioned this more clearly in etc/ORG-NEWS, I agree we should provide users with the relevant information here. Thanks, -- Bastien