Open tajmone opened 3 years ago
It would really great if Windows users could install the PML converter app via the Chocolatey package manager
Yes, but ...
When I created the PML website, I tried to create a Chocolatey package for PML. My subjective experience with Chocolatey was that it is easy to use for end-users, but cumbersome for developers (for different reasons not explained here). I found it to be a frustrating experience to create and publish a PML package, and I finally gave up, because there will be winget, a native Windows solution to automate the installation/update process.
Once winget will be a standard feature of Windows, other package managers might fade away. A quick look at winget's documentation reveals that it's very easy to create a winget package:
According to the Roadmap version 1.0 will be available in May 2021.
So maybe we should investigate and try out the current preview version.
PML installation currently requires restarting Windows
Yes, and that's not good. The only reason for restarting is because of the OS PATH
variable that is changed during installation. As far as I know there is no native solution in Windows to avoid restarting after changing PATH. Maybe winget solves this problem.
Unfortunately there is still no easy solution to create stand-alone distributions for Java applications. The current procedure to create a PML distribution for Windows is as follows:
It's cumbersome for maintainers and far from ideal for users, because of the need for restarting the computer, and the lack of automatic update functionality.
A PML package for a natively supported Windows package manager would be a far better solution.
As for Linux, I use jpackage to create a .deb or .rpm file. PML installation/updates are done with a Linux command like sudo apt-get install ./pml-to-html-converter_1.3.0-1_amd64.deb
. The OS PATH
variable must be set manually (not user-friendly too, but less problematic in the Linux world where users are generally more technical oriented).
jpackage
in Java 16 now also supports pkg
and dmg
packages for macOS, so in the future PML should be available for Apple users too.
My subjective experience with Chocolatey was that it is easy to use for end-users, but cumbersome for developers (for different reasons not explained here).
I see. But it doesn't surprise me either, because complex software packages often break up in Chocolatey, so maybe it's not viable except for simple standalone tools or software with standard installers (like NSIS) which can be run in silent mode.
there will be winget, a native Windows solution to automate the installation/update process.
Once winget will be a standard feature of Windows, other package managers might fade away.
That sounds a better solution. I completely forgot about it, I stumbled upon it a couple of times but never dug into it because it was still a Windows Insiders feature. I'm sure that MS will release it as soon as possible, they're working quite fast with Win 10 feature lately.
Yes, and that's not good. The only reason for restarting is because of the OS PATH variable that is changed during installation. As far as I know there is no native solution in Windows to avoid restarting after changing PATH. Maybe winget solves this problem.
Strange, I thought that under Win 10 this problem only affected open CDM sessions. I'm pretty sure that this is the case when altering the User PATH. I'll try and see if I found some articles on this topic, now you got me curious.
Unfortunately there is still no easy solution to create stand-alone distributions for Java applications.
Yes, that's another reason why I'm not a huge fan of Java, and the fact that it doesn't allow you to create a static or dynamic library version of an app, to integrate it into other tools. I tend to prefer stand alone binary executable tools, whenever I have a choice, because they easily allow you to keep older binary versions in outdated projects, without conflicts with later versions on the SYS PATH.
Hi,
I have some experience with various package managers in the Windows environment. Perhaps there might be some suggestions here that you might find useful?
BoxStarter uses Chocolatey packages and easily handles software installs that require server reboots. It is designed for a commercial production environment, so it might be overkill in this situation.
However, there is a simpler alternative. When a Chocolatey install requires an update of say, PATH, or other environment variables, it can be done without a reboot by using the RefreshEnv.cmd, which is installed as part of Chocolatey. Could this be adapted for your situation?
If there is an option to install via Chocolatey or Scoop, my preference is Scoop. It is designed primarily for CLI applications and their package maintainers tend to keep them more up-to-date than those maintaining Chocolatey. It doesn't require admin privileges and applications are installed in a users "home" directory.
Most of the initial applications were from the MSYS / Cygwin project. The core applications are shown in the "main" Scoop bucket. It is from here, for example, that I install 7zip, git, pandoc, perl, and python. I use the "extras" bucket for bleachbit, everything, fiddler, languagetool, signal, sqlitebrowser and winmerge. The scoop page on GitHub gives a list of all the known buckets.
The pandoc.json files shows the typical configuration. There are also example setup scripts in the wiki. As a user, I am a huge fan of Scoop. However, I don't know if it is difficult to setup from a developer's viewpoint. It might be worth investigating, in any case.
Zero Install has a much smaller footprint than any of the other package managers. It has fewer applications, but it has the simplest installation. Security is a core principle along with non-admin users being able to install applications. An application can be "run" without being installed -- an interesting way of testing an application. The distinctive features can be seen on the comparison page.
The ffmpeg page, for example, shows that the configuration is an XML file. The packaging overview explains the details.
It would be great if you could use Scoop to package your application. But there might be other alternatives. I trust that what I have mentioned will give you some food for thought.
Kind Regards, Liam
Very interesting.
some food for thought
Indeed. I will have a look at these solutions.
Thank you very much for the links.
thanks @celtic-coder, your links and reviews are really useful.
The no-reboot env refresher batch script is a true gem!
I knew about Scoop, but never actually used it (mostly because some package I need are only available through Chocolatey) even though my impression has it's better than Chocolatey in many respects.
I didn't know about Zero Install, and it's a nice solution since it's cross platform.
Maybe, if packages configurations can be auto-updated via some CI task at each new PML release, it might be worth offering end users different installation solutions. Those users who already use Chocolatey, Scoop, etc., might appreciate a PML package for their preferred package manager.
Hi,
This is just an FYI.
I came across this repo listing for Sublime Text today, which gives Chocolatey and Scoop as the two of the Windows package installers. It also mentions just-install, which I have not used.
The instructions for adding a new package to the "registry" look to be fairly straightforward. It has 273 packages and has been going since April 2018, so it may be worth considering for PML at some stage in the future.
Kind Regards, Liam
just-install seems fairly simple to use, both for end users (can invoke it via command line in any shell, whether the CMD, PowerShell, Bash, etc.) as well as for package developers (from a quick peek at the JSON Registry format I got the impression it's easier than Chocolatey). Having said that, I didn't really experiment with it, just sifted through the documentation.
It would be nice if there was a GUI front end, like Chocolatey GUI for Chocolatey, because I guess it's the kind of extra tool that can make the difference in terms of which package manager end users will adopt.
I do though agree with @pml-lang that once Windows Package Manager and winget become stable, and officially incorporated in Windows, it might become the first choice. It's quite possible that once winget is out we will simply see all package from these other tools migrate to it, since they were created to fill-in the lack of an official package manager.
Sure, if there is an easy way to automate the update process of PML packages for the other package managers, it might be still worth keeping them (e.g. for older versions of Windows, which might not benefit from winget) — but maybe just barely. It really depends on whether winget is going to be strongly promoted by MS at launch, or if it will just end up being some obscure tool buried among the many other developer or admin tools present in Win 10.
Hi Christian (@pml-lang),
Recently, I stumbled on JReleaser. It describes itself as "The quick and effortless way to release your Java project!"
One of the features that is interesting, in the light of the discussion above, is:
JReleaser can package your application to be distributed with popular software packagers such as Homebrew, Scoop, Chocolatey, Snapcraft, and others.
One more item to add to the To-Do list, perhaps? 😄
Kind Regards, Liam
JReleaser can package your application to be distributed with popular software packagers such as Homebrew, Scoop, Chocolatey, Snapcraft, and others.
That sounds fantastic. Will have a close look at it.
Thanks a lot for the link.
Good news: Windows Package Manager 1.0.
It would really great if Windows users could install the PML converter app via the Chocolatey package manager, which greatly simplifies updates since it can fully automate the process, from un-installing previous versions, to dealing with dependencies, the registry, etc.
Thanks to the official Chocolatey GUI app, it's even easier to install and update packages, without having to use the command line.
Chocolatey packages are usually hosted on GitHub, and being just PowerShell scripts its common practice to integrate these packages to their original project via automation tools that can update the PS scripts whenever a new version is released — it boils down to recreating the PS scripts with updated version info, links, etc., and then updating the package info on Chocolatey's website.
In my experience, Chocolatey packages are only worth using if they're created by the official maintainers of a project (third party packages often end up going stale when users loose interest in the app/package), especially because of the auto-generated updates offering a strong guarantee that each new product release will be followed immediately by its Choco package being updated.
Creating the initial package might require some reading, because there are tons of settings on Chocolatey, and different ways to handle silent installations, default settings, etc.
https://docs.chocolatey.org/en-us/create/
I've noticed that PML installation currently requires restarting Windows for the process to complete. This might be a problem with Chololatey, and I'm not sure if it can handle (or allows) this, because end users must be able to auto-update multiple packages at once.
I'm not well versed in PowerShell (and it's many incarnations), so I might not of great help here, but I'm willing to dig through the Chocolatey and PowerShell docs it this might help. IMO, it shouldn't be too hard to create a Choco package, but i might require some local testing before publishing, especially for the part concerning auto-updating the Choco files from the PML repository (via some CI service like Travis CI, Circle CI, or GitHub Actions) whenever a new tagged release is published.
But I believe that being able to offer a PML Chocolatey package would be a great incentive for end users, and it would ensure that they'll always have an up to date PML converter without having to go through the manual process.