3 ms·

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

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.

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.