pip/pip3 confusion and keeping up to date

[Jon Ribbens]

On 2023-11-05, Chris Green <cl at isbd.net> wrote:
> Jon Ribbens <jon+usenet at unequivocal.eu> wrote:
>> On 2023-11-03, Karsten Hilbert <Karsten.Hilbert at gmx.net> wrote:
>> > Am Thu, Nov 02, 2023 at 04:07:33PM -0600 schrieb Mats Wichmann via Python-list:
>> >> >So they now have only python3 and there is no python executable in
>> >> >PATH.
>> >>
>> >> FWIW, for this you install the little stub package python-is-python3.
>> >> Especially if you want to keep a python2 installation around -
>> >> "python" will still be python3 in this case.
>> >
>> > Since you seem knowledgeable in this area: Do you know of a
>> > resource for learning the *canonical* way of packaging a
>> > Python application for installation via apt which
>> >
>> > - needs some packages available via apt
>> > - needs some packages only available via pip
>> > - needs some packages newer than what is available via apt
>> >
>> > ?
>> 
>> I suspect the answer to that is that you would have to:
>> 
>>   * create packages yourself for the unpackaged dependencies
>>   * create a dependency graph of *every* Python package in the package
>>     repository (whether or not the package is relevant to what you're doing)
>>   * work out what versions of every Python package are required in order
>>     to have a dependency graph that can be successfully resolved, taking
>>     into account the requirements of your new package also
>>   * contact every single maintainer of every single one of the packages
>>     that needs updating and persuade them to update their packages and
>>     reassure them that you are getting all the other package maintainers
>>     to update their packages accordingly and that you have a plan and
>>     that you know what you're doing
>> 
>>   ... screen fades to black, title card "3 years later", fade in to ...
>> 
>>   * publish your package
>> 
> Surely it's not that bad, the vast bulk of Debian, Ubuntu and other
> distributions are installed via systems that sort out dependencies once
> given a particular package's requirements.  Python is surely not
> unique in its dependency requirements.

I think there's a lot of work that goes on behind the scenes to keep the
entire package set consistent so that you don't end up in the situation
where, e.g. package A depends on D<2.0 and package B requires D>=2.0 and
therefore you can't install A and B at the same time (and trying to
avoid as much as possible the hacky situation where you have two
packages for D, one for <2.0 and another called D2 for >=2.0).