Identify other candidate package managers

[jasercion]

We need to identify additional package managers to target for Fermitools distribution other than Conda. Opening this issue to have a trackable location for discussion/decision making on this.

Current top-line suggestions include pixi and pip. Brew, apt, and yum have also been suggested.

[Areustle]

This is a meta tracker for packages in package manager repos. Lot's of useful information here as far as selecting PMs to target.

https://repology.org/

My top suggestions:

• pip
• yum
• homebrew
• conda-forge (rather than our conda/fermi channel)

lower priority but still valueable

• apt
• AUR / Archlinux
• nix

[JamesAmrhein]

My order would be:

• Pixi is a versatile developer workflow tool designed to streamline the management of your project’s dependencies, tasks, and environments. Built on top of the Conda ecosystem, Pixi offers seamless integration with the PyPI ecosystem. #Support for both Python ecosystems?
• conda-forge # Agree with Alex, generalize away from Anaconda specific support.
  Hopefully will be the fastest to implement, but Anaconda could still pull the rug from under the community if they restrict conda-forge.
• pip. # Python - Completely Un-Anaconda
• apt # Ubuntu (Currently CI/CD Linux OS support). # Yum is not available on Ubuntu after 18.04
• Homebrew # MacOS (Currently CI/CD Mac OS support)
• DNF (YUM replacement) # CentOS/RedHat

[dagorym]

I'd agree that apt should take precedence over yum/DNF. If you install Windows Subsystem for Linux you get Ubuntu by default and all the Linux systems I deal with anymore are Ubuntu not Red Hat based. So at least in my experience that would be more broadly useful option.

[robincorbet]

Are all of these open source?

[jasercion]

Yes, unless I'm mistaken all of these are open source.

From the responses, I'd propose starting with pip, apt, and homebrew since those are all very well established, standard projects and it gives us pretty solid coverage across supported systems. There's also a ton of existing tools and resources on packaging for these so it should make setting things up to accommodate them much more straightforward.

The main reason I hesitate on Conda-forge is the use of the feedstock-based system needing its own separate accommodations outside of our own pipeline. I don't think it should be ruled out, but it does introduce another thing we will need to separately set up and maintain.

Pixi would be something I'd need to look into further - I don't know anything about it.

[jasercion]

From a quick look through the conda packaging documentation, it looks like there is a standard way to generate pip products using that system so supporting that should be low-hanging fruit.
While we wait for additional input from folks who are currently out, I suggest moving forward now with

• Pip
• Homebrew

and continuing the discussion as we work on those as to what should be the next priority.