How would you then resolve the following scenarios:
1) I need to have two applications running on the same host with different Python versions. E.g. Python 2.6 and Python 2.7. apt would only support one of the Python 2.x line installed at a time.
2) I need to have two applications that have conflicting version requirements on the same host. E.g. neither set of requirements can be installed at the same time.
3) I need to install a newer version of a Python library than the one in apt. If I install it into the system Python via pip, now apt is out of sync with what is actually installed.
4) I need to install a version of a Python library that conflicts with the requirements of system tools that rely on the system-installed Python. If I install said library, then the system tools will stop working / break down.
Also "checkout into your project directory and call `import`" doesn't scale. Maybe it works well for toy projects and one-off things, but not so much at scale.
> 1) I need to have two applications running on the same host with different Python versions. E.g. Python 2.6 and Python 2.7. apt would only support one of the Python 2.x line installed at a time.
I take it you haven't used Debian/APT for last three or four releases, because
what you assert (only one Python 2.x version per host) is just plain invalid.
> 3) I need to install a newer version of a Python library than the one in apt. If I install it into the system Python via pip, now apt is out of sync with what is actually installed.
Uhm... I don't know why you have a problem with building your own package with
the newer version. I do it all the time, for software both others' and mine.
This leaves points 2) and 4), which are essentially the same: how to install
two conflicting versions of the same module for two different applications
(one of which may come from the distribution), but this is not a problem with
dpkg or RPM, this is a problem with Python's module lookup mechanism. For
C libraries there are already good protocols for handling this issue (a little
different for RPM and dpkg).
> Uhm... I don't know why you have a problem with building your own package with the newer version. I do it all the time, for software both others' and mine.
Maybe things have improved in the past few years, but last time that I built a dpkg for a Python library it was far from painless, even with some wrapper off the Debian wiki specifically for that use-case (and I was just doing this for pure-Python).
I've dealt with building both RPM and DPKG packages in the past, and I recall all of the build tools for each being far from ideal, and even the use case of "I want to package up a list of files and install them to a specific location" was far more difficult that it should have been. The biggest issue being that most of the tooling is based on the use-case of taking a tar of sources files, and running it though autoconf-esque build process to build it, apply patches, etc, which might be great for prolific package maintainers, but make things a bit more daunting for the new / causal user that just wants to create a simple package.
> how to install two conflicting versions of the same module for two different applications (one of which may come from the distribution), but this is not a problem with dpkg or RPM, this is a problem with Python's module lookup mechanism
Regardless it is an issue that exists. The parent post was saying that "apt should be good enough for all use-cases" which I was rebutting. I wasn't claiming that APT was sucky / broken, but that it doesn't handle all Python use-cases well. Whether it is the fault of APT or Python as to why they might be incompatible in a specific use-case is sort of irrelevant if you end up needing account for said use-case.
> For C libraries there are already good protocols for handling this issue (a little different for RPM and dpkg).
I'm not fully versed in the mechanisms in C, but IIRC, isn't that why packages are renamed when breaking changes happen over major versions (e.g. libxml vs. libxml2 / libgtk2 vs. libgtk3)? "Rename the package" seems more like a work-around than a system to handle the issue at hand. You're not saying, "I want libgtk with version 3.x".
>> Uhm... I don't know why you have a problem with building your own package with the newer version. I do it all the time, for software both others' and mine.
> Maybe things have improved in the past few years, but last time that I built a dpkg for a Python library it was far from painless
"Past few Debian releases", since debhelper 7.x, not "years" (well, this
incidentally matches, too). Debhelper can build properly Python using
setup.py and doesn't require anything special (no need to specify any paths)
to put artifacts where they can be found by /usr/bin/python. It's actually
easier than building analogous C code, since you don't even specify where to
put what.
> [libxml vs. libxml2 / libgtk2 vs. libgtk3] "Rename the package" seems more like a work-around than a system to handle the issue at hand. You're not saying, "I want libgtk with version 3.x".
For DEBs, yes, this is the case, but you can have several RPMs with the same
name but different version.
On the other hand, working with the OS is much easier when the packages differ
in their name, so this "workaround" is much more pleasant to use, even though
it's not a "pure" solution.
1,2,3,4) You target a specific version of Debian during development and your software will be easily deployable for 5 years without requiring Python-specific knowledge and its dependencies will receive security updates from the distribution.
1) I need to have two applications running on the same host with different Python versions. E.g. Python 2.6 and Python 2.7. apt would only support one of the Python 2.x line installed at a time.
2) I need to have two applications that have conflicting version requirements on the same host. E.g. neither set of requirements can be installed at the same time.
3) I need to install a newer version of a Python library than the one in apt. If I install it into the system Python via pip, now apt is out of sync with what is actually installed.
4) I need to install a version of a Python library that conflicts with the requirements of system tools that rely on the system-installed Python. If I install said library, then the system tools will stop working / break down.
Also "checkout into your project directory and call `import`" doesn't scale. Maybe it works well for toy projects and one-off things, but not so much at scale.