-
Notifications
You must be signed in to change notification settings - Fork 108
Using fpm to upgrade fpm itself #344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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
This would clone into a temporary directory, build the project and install into |
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.
seems nice to me, though not as easy as |
|
Why? What fpm installed packages depend on an fpm binary? |
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 |
I also add that I think the misunderstanding above suggests one more potential problem: IIRC |
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. :)
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 |
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. 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 |
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 new
a dummy project.fpm install
. This will build thefpm
library 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?
The text was updated successfully, but these errors were encountered: