fortran-lang
Using fpm to upgrade fpm itself
Say I have fpm-0.1.3 and want to upgrade to current master or some future tag like v0.1.4. After the step 2 of #253 is implemented (so that the fpm.toml is in root dir), I think this should be possible by going through the following steps:
fpm newa dummy project.- Add fpm as a dependency to the manifest and specify the v0.1.4 tag.
- Run
fpm install. This will build thefpmlibrary and binary as a dependency and put it to ~/.local/bin.
This will be somewhat awkward and not easy to do. Having the fpm upgrade command do this for you would be useful and nice UX I think.
What do you think?
This workflow can't work, executables are currently only installed from the root project but not from the dependencies and I don't think it is a good idea to change this behaviour.
Maybe a more pip like syntax could be desirable here
fpm install https://github.com/fortran-lang/fpm
This would clone into a temporary directory, build the project and install into ~/.local/bin.
Yes, I didn't suggest that workflow as a solution, but used it as an example of what the user would have to do if it had worked as I thought.
fpm install https://github.com/fortran-lang/fpm
seems nice to me, though not as easy as fpm upgrade. What do you think about this command being an alias for what you suggested?
fpm upgrade would require a local registry of fpm installed packages to check for all packages that should be updated.
Ah, now I understand, we are talking about a self-upgrade command here. I thought we are talking about a general upgrade strategy and fpm was used as example.
Just as a note, self-upgrading programs are usually not well-received in most packaging ecosystems (except maybe in their own one). The user experience of updating fpm would preferably boil down to pacman -Syu fpm, brew upgrade fpm or mamba update fpm. I'm not sure if fpm has to roll its own self-updating strategy at all.
I also add that I think the misunderstanding above suggests one more potential problem: IIRC fpm update updates the dependencies of the project, whereas the proposed fpm upgrade would be an upgrade of fpm itself. This is somehow inconsistent and can confuse the user.
self-upgrading programs are usually not well-received in most packaging ecosystems (except maybe in their own one)
This is no surprise for obvious reasons. I would too recommend that people don't write self-upgrading fpm packages, but to use fpm to do that for them. :)
The user experience of updating fpm would preferably boil down to pacman -Syu fpm, brew upgrade fpm or mamba update fpm.
In theory, I think you're right, but in practice it doesn't work. There are so many system-specific package managers that there would be a lot of work for the fpm developers to keep shipping updates on all of them. System-specific managers also have an end-of-life for updates.
I don't think this is a priority now, but wanted to get a pulse from people. It could also be a plugin (#211) or 3rd party tool, so people like me who want to use it, can.
On Windows there's a problem when trying to upgrade a program that is currently running (already in use Error). On Linux, it should work.
Tentative implementation https://gist.github.com/brocolis/e2fc06743652f939d95d351b16721f5c
If the Fortran fpm becomes a Fortran fpm package as @LKedward suggests in #362 then you can do
git clone https:/fpm_home/fpm.git
cd fpm
fpm install
and if you already have and fpm/ directory just enter it and do
git pull
fpm install
which would just leave the bootstrap issue. So an upgrade does not seem all that cumbersome; even if you do it more cautiously and do a upgrade of the external packages and a build and run the tests before an install. But I would like a simple one-line command to pull a github site with fpm support; build and test and install it and remove the directory.
As long as fpm remains a pure Fortran program that is all free-format not using INCLUDE files it is pretty easy to make a single-file fpm.f90 bootstrap file too. Since there are other reasons to make f-fpm an fpm package that seems like that would make it reasonably easy if not quite "yum install fpm". The "other fpm" purports to be able to make many different package formats, although I have not looked into that too much; but there are already binary fpm distributions available for a number of platforms. The fortran-lang page talking about setting up Fortran should maybe have a link to the fpm setup page? So far fpm is more system-independent than a lot of package managers so using it to package itself does not seem too bad to me.
I know of at least one other package manager that has the following behavior, Haskell's stack. If the current working directory is not within an fpm package, then the command fpm install package_name would effectively do what @urbanjost suggested; download the latest version of that package, build it, and install it. If we get around to doing local caching of packages correctly, then there may not be a reason to delete the package once it's installed.
