fpm on PyPi

[gnikit]

Have you considered releasing fpm through PyPi? I think there is a way to get the conda-forge feedstock to also publish on PyPi.

While trying to see if fpm is available through PyPi I also saw that someone is name-squatting on the name, along with a plethora of other very common names, see. Regardless of if you publish on PyPi it might be a good idea to file a PEP 451 request to reserve fpm for the organisation.

For more see: pypi/warehouse#4004

[awvwgk]

Why would we want to pip install fpm? I know that CMake and ninja are doing this by building wheels with additional Python wrappers which than invoke the real binary. I have been using those in CI a bit, but eventually felt that it was easier to just install it directly via conda.

[gnikit]

BTW @awvwgk I feel I should provide some context as to why we would "need" pip instead of Anaconda. It is trivial to install packages with pip in VS Code so that would be an easy way to install fpm to people's machines. Anaconda on the other hand would be a nightmare since we would have to make our vscode-fortran-support extension manage conda environments.

I will try and have a look by the end of the week. Cheers for the input!

[awvwgk]

Supporting micromamba as VS Code extensions seems like an effort very much worth the time then. Fitting a binary package in a Python wheel is a very crude workaround IMO.

[gnikit]

The problem I see is the added complexity to the extension. We would effectively have to rewrite a subset of the VS Code Python extension, which does support Anaconda. And then we would have to make people download Anaconda (and set it up correctly so that we can detect it from NodeJS).

micromamba seems very promising but from my experience users tend to get very upset when you install things on their system that they haven't heard about or don't think they are necessary. (also I think it will suffer from the same challenges as anaconda)

A big challenge I see on the horizon with anaconda and micromamba is the need to communicate the initialised environment variables from the core of the extension, to the terminal windows at the bottom of VS Code, to the side panel actions and to the VS Code build system. That is a lot of work for something that is not integral to the extension and it's more a nice-to-have feature.

IMO pip is a very low bar to clear since it comes with Python nowadays. Installing fpm through pip is not probably the best idea if you want to deploy to an HPC but for local development in a user level I don't see any caveats. Are there any issues/conflicts that you can foresee with a pip --user installation?

PS I found this VS Code project that claims to allow for micromamba usage but it is in a prenatal state: https://marketplace.visualstudio.com/items?itemName=corker.vscode-micromamba

[awvwgk]

I have no experience with pip installing software outside of conda environments, I had to fix a few Python installations of coworkers who did break their machine with [sudo] pip install from time to time, but those are more anecdotal.

[gnikit]

Yeah, I wouldn't expect us doing anything as destructive as this. In VS Code specifically we run {default-python} -m pip install --user --upgrade {package-name} which installs locally and does not break anything. Also because fpm is not a Python package and has virtually no Python dependencies even if we wanted we couldn't break peoples' packages.

I was hoping we could be lazy and just piggyback on the existing conda-forge binaries but from the looks of CMake 1 we will have to be way more explicit.

Do you see another way of doing this? AFAIK as I know there is no easy way to go from Anaconda to PyPi.