4 ms·

Can someone make the case for distributing python packages at the distro level to me? Especially scientific software for data analysis? Our project gets a few

Can someone make the case for distributing python packages at the distro level to me? Especially scientific software for data analysis? Our project gets a few issues opened by distro maintainers who have trouble with some part of their build process. Is it really worth our project maintainers time to help troubleshoot esoteric build processes when we already provide source, wheel, and conda distributions?

nerdponx 5y ago
I don't know what your project is specifically, but it's reasonable that a system-level user-facing application might want to depend on Numpy or Scipy.
Sesse__ 5y ago
Users generally don't want Python packages; they want software. They don't care what it's written in, and shouldn't have to install it differently depending on what you chose. “Just learn $language_package_manager_of_the_day, and hope it doesn't break anything when your system changes” is the equivalent of the 90s “./configure ; make ; make install”, and we should have moved past that for end-users by now. Most users are not developers, and installation procedures need to cater to both.
- ivirshup 5y ago
  But our package is for scientific data analysis. It’s a python library. If you’re distributing an application, shouldn’t you just ship an environment with our package bundled?
  - rbanffy 5y ago
    > shouldn’t you just ship an environment with our package bundled? That's how I would prefer it, but, if the intended form of distribution is a distro package, then it should pin itself to the versions the distro provides and avoid (or vendor in) packages that aren't available. It is possible to just place everything in the app directory and distribute it this way, but it's kind of ugly (and doesn't pick up security updates from the distro)
  - ginko 5y ago
    I would expect libraries to be distributed as a separate distro package like every other library in the system. Why shouldn't it?
  - blacklion 5y ago
    > If you’re distributing an application, shouldn’t you just ship an environment with our package bundled? No-no-no-no! If you (application author & distributor) do so, you are obligated to release new version of your application (which includes 3rd party libraries as "environment") each time your dependencies are updated due to security reasons. Do you know many application maintainers who want to do so? If your application depends on system-installed (distro-provided) libraries (python modules, native libraries, whatever) it is responsibility of distro maintainers do not have versions with known security problems in system-wide repo. It is much better for you (app author & mainitainer) and me (distro user & admin), IMHO.
rbanffy 5y ago
What I suggested was for the package owner (I build a font that's also distributed as part of Debian) to do whatever they needed to make their lives easier. It was a long time ago, but, I remember they made a couple changes and improvements to the Makefile that streamlined their side of the operation. They maintain a fork of my repo.
enriquto 5y ago
> Can someone make the case for distributing python packages at the distro level to me? Especially scientific software for data analysis? As a matter of principle, I prefer to avoid software from non-curated repositories like pip and the like. Installing the debian-provided scipy and numpy is more than enough for me. I don't understand what's so special about python that needs its own "package manager" when the distro-provided one is already good. If I need something, I install it using "apt install", regardless of what language it is written in.
michaelt 5y ago
The main reason to distribute python packages at the distro level is: Because something else distributed at the distro level depends on them. For example, if gnuradio requires numpy then a distro that won't distribute numpy can't distribute gnuradio

nerdponx 5y ago

I don't know what your project is specifically, but it's reasonable that a system-level user-facing application might want to depend on Numpy or Scipy.

Sesse__ 5y ago

Users generally don't want Python packages; they want software. They don't care what it's written in, and shouldn't have to install it differently depending on what you chose. “Just learn $language_package_manager_of_the_day, and hope it doesn't break anything when your system changes” is the equivalent of the 90s “./configure ; make ; make install”, and we should have moved past that for end-users by now. Most users are not developers, and installation procedures need to cater to both.

ivirshup 5y ago
But our package is for scientific data analysis. It’s a python library. If you’re distributing an application, shouldn’t you just ship an environment with our package bundled?
- rbanffy 5y ago
  > shouldn’t you just ship an environment with our package bundled? That's how I would prefer it, but, if the intended form of distribution is a distro package, then it should pin itself to the versions the distro provides and avoid (or vendor in) packages that aren't available. It is possible to just place everything in the app directory and distribute it this way, but it's kind of ugly (and doesn't pick up security updates from the distro)
- ginko 5y ago
  I would expect libraries to be distributed as a separate distro package like every other library in the system. Why shouldn't it?
- blacklion 5y ago
  > If you’re distributing an application, shouldn’t you just ship an environment with our package bundled? No-no-no-no! If you (application author & distributor) do so, you are obligated to release new version of your application (which includes 3rd party libraries as "environment") each time your dependencies are updated due to security reasons. Do you know many application maintainers who want to do so? If your application depends on system-installed (distro-provided) libraries (python modules, native libraries, whatever) it is responsibility of distro maintainers do not have versions with known security problems in system-wide repo. It is much better for you (app author & mainitainer) and me (distro user & admin), IMHO.

rbanffy 5y ago

What I suggested was for the package owner (I build a font that's also distributed as part of Debian) to do whatever they needed to make their lives easier. It was a long time ago, but, I remember they made a couple changes and improvements to the Makefile that streamlined their side of the operation. They maintain a fork of my repo.

enriquto 5y ago

> Can someone make the case for distributing python packages at the distro level to me? Especially scientific software for data analysis? As a matter of principle, I prefer to avoid software from non-curated repositories like pip and the like. Installing the debian-provided scipy and numpy is more than enough for me. I don't understand what's so special about python that needs its own "package manager" when the distro-provided one is already good. If I need something, I install it using "apt install", regardless of what language it is written in.

michaelt 5y ago

The main reason to distribute python packages at the distro level is: Because something else distributed at the distro level depends on them. For example, if gnuradio requires numpy then a distro that won't distribute numpy can't distribute gnuradio