Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #13192 > unrolled thread

upstream python concerns, python3-full package for bullseye

Back to article view | Back to linux.debian.maint.python

Contents

  upstream python concerns, python3-full package for bullseye Elana Hashman <ehashman@debian.org> - 2021-02-11 19:20 +0100
    Re: upstream python concerns, python3-full package for bullseye Stefano Rivera <stefanor@debian.org> - 2021-02-11 19:30 +0100
      Re: upstream python concerns, python3-full package for bullseye Stefano Rivera <stefanor@debian.org> - 2021-02-16 05:30 +0100
        Re: upstream python concerns, python3-full package for bullseye Thomas Goirand <zigo@debian.org> - 2021-02-16 17:30 +0100
    Re: upstream python concerns, python3-full package for bullseye Thomas Goirand <zigo@debian.org> - 2021-02-12 01:20 +0100
      Re: upstream python concerns, python3-full package for bullseye stefanor@debian.org - 2021-02-12 01:50 +0100
        Re: upstream python concerns, python3-full package for bullseye Thomas Goirand <zigo@debian.org> - 2021-02-12 09:20 +0100
          Re: upstream python concerns, python3-full package for bullseye Raphael Hertzog <hertzog@debian.org> - 2021-02-12 09:40 +0100
            Re: upstream python concerns, python3-full package for bullseye Thomas Goirand <zigo@debian.org> - 2021-02-12 10:20 +0100
              Re: upstream python concerns, python3-full package for bullseye Martin <debacle@debian.org> - 2021-02-12 11:30 +0100
              Re: upstream python concerns, python3-full package for bullseye Christian Kastner <ckk@debian.org> - 2021-02-12 13:20 +0100
              Re: upstream python concerns, python3-full package for bullseye Julien Palard <julien@palard.fr> - 2021-02-12 14:10 +0100
                Re: upstream python concerns, python3-full package for bullseye Matthias Klose <doko@debian.org> - 2021-02-12 17:40 +0100
                Re: upstream python concerns, python3-full package for bullseye Thomas Goirand <zigo@debian.org> - 2021-02-13 23:10 +0100
              Re: upstream python concerns, python3-full package for bullseye Stefano Rivera <stefanor@debian.org> - 2021-02-12 21:20 +0100
          Re: upstream python concerns, python3-full package for bullseye Stefano Rivera <stefanor@debian.org> - 2021-02-12 21:00 +0100
            Re: upstream python concerns, python3-full package for bullseye Michael Kesper <mkesper@schokokeks.org> - 2021-02-12 21:50 +0100
        Re: upstream python concerns, python3-full package for bullseye Tristan Seligmann <mithrandi@mithrandi.net> - 2021-02-12 10:30 +0100
          Re: upstream python concerns, python3-full package for bullseye Valentin Vidic <vvidic@debian.org> - 2021-02-12 10:50 +0100
            Re: upstream python concerns, python3-full package for bullseye Jonathan Carter <jcc@debian.org> - 2021-02-12 11:40 +0100
              Re: upstream python concerns, python3-full package for bullseye Valentin Vidic <vvidic@debian.org> - 2021-02-12 12:10 +0100
            Re: upstream python concerns, python3-full package for bullseye Simon McVittie <smcv@debian.org> - 2021-02-12 15:20 +0100
              Re: upstream python concerns, python3-full package for bullseye Andrius Merkys <merkys@debian.org> - 2021-02-12 17:00 +0100
                Re: upstream python concerns, python3-full package for bullseye Valentin Vidic <vvidic@debian.org> - 2021-02-12 17:20 +0100
      Re: upstream python concerns, python3-full package for bullseye Michael Kesper <mkesper@schokokeks.org> - 2021-02-12 11:00 +0100
      Re: upstream python concerns, python3-full package for bullseye Jeremy Stanley <fungi@yuggoth.org> - 2021-02-12 18:00 +0100
      Re: upstream python concerns, python3-full package for bullseye Bastian Venthur <venthur@debian.org> - 2021-02-16 10:20 +0100
        Re: upstream python concerns, python3-full package for bullseye Stefano Rivera <stefanor@debian.org> - 2021-02-16 19:30 +0100
          Re: upstream python concerns, python3-full package for bullseye Jeremy Stanley <fungi@yuggoth.org> - 2021-02-16 20:20 +0100
        Python package situation Martin <debacle@debian.org> - 2021-02-16 21:50 +0100
          Re: Python package situation Andrey Rahmatullin <wrar@debian.org> - 2021-02-16 22:20 +0100
            Re: Python package situation Martin <debacle@debian.org> - 2021-02-16 23:20 +0100
            Re: Python package situation Brian May <bam@debian.org> - 2021-02-17 02:10 +0100
              Re: Python package situation Andrey Rahmatullin <wrar@debian.org> - 2021-02-17 08:00 +0100
              Re: Python package situation Raphael Hertzog <hertzog@debian.org> - 2021-02-17 10:30 +0100

Page 2 of 2 — ← Prev page 1 [2]

#13205

On Fri, Feb 12, 2021 at 12:37:39PM +0200, Jonathan Carter wrote:
> I saw some discussion about this before, and it does sound nice, but it
> would require change to a few thousand packages to handle such a
> transition, where adding python3-full doesn't really add work for anyone
> except maintaining another meta-package.

Not sure what you mean, AFAICT python3-core and python3-full don't exist
in Debian at the moment. I'm just suggesting that python3-core might be
a better name for this meta-package than python3-full.

-- 
Valentin

[toc] | [prev] | [next] | [standalone]

#13208

On Fri, 12 Feb 2021 at 10:40:48 +0100, Valentin Vidic wrote:
> Perhaps python3-core would be more appropriate, and python3-full can be
> left for something even bigger.

We have a python3 package already. If I saw a python3 package and a
python3-core package, I would expect that either they're the same thing,
or python3-core is a smaller and less fully-featured version of python3.

Conversely, we already have a python3-minimal package, and I would expect
python3-core to be larger and more fully-featured than python3-minimal
(or maybe the same), because by definition if it's minimal then it's
the least Python you can have. So:

    python3-minimal ≤ python3-core ≤ python3 ≤ python3-full

Changing the meaning of the python3 name is not an option right now,
because that would be a disruptive change, and we're already in the
Debian 11 freeze.

If we want to have a metapackage that is "larger" than our current python3,
then the only option that's really feasible for Debian 11 is for that
larger metapackage to have a new name that is chosen to imply "this is
larger than python3", like python3-full.

> collectd-core - statistics collection and monitoring daemon (core system)
> gnome-core - GNOME Desktop Environment -- essential components

collectd-core is smaller than collectd, gnome-core is smaller than gnome,
and so on.

    smcv

[toc] | [prev] | [next] | [standalone]

#13209

On 2021-02-12 16:18, Simon McVittie wrote:
> We have a python3 package already. If I saw a python3 package and a
> python3-core package, I would expect that either they're the same thing,
> or python3-core is a smaller and less fully-featured version of python3.
> 
> Conversely, we already have a python3-minimal package, and I would expect
> python3-core to be larger and more fully-featured than python3-minimal
> (or maybe the same), because by definition if it's minimal then it's
> the least Python you can have. So:
> 
>     python3-minimal ≤ python3-core ≤ python3 ≤ python3-full

+1. Exactly how I would understand these names.

Andrius

[toc] | [prev] | [next] | [standalone]

#13210

On Fri, Feb 12, 2021 at 05:59:12PM +0200, Andrius Merkys wrote:
> On 2021-02-12 16:18, Simon McVittie wrote:
> >     python3-minimal ≤ python3-core ≤ python3 ≤ python3-full
> 
> +1. Exactly how I would understand these names.

I see your point too. I guess python3-full is the way to go then,
but maybe also leave it at that if we don't want to bloat python3
too much (python3 becomes python3-core and python3-full becomes
python3).

-- 
Valentin

[toc] | [prev] | [next] | [standalone]

#13202

[Multipart message — attachments visible in raw view] — view raw

Hi all,

Am 12.02.21 um 01:11 schrieb Thomas Goirand:
> Hi Elana,
> 
> Thanks for bringing this topic in the channel, and speaking with the
> Python Steering Council, plus Mathias and Stefano. That's very much
> appreciated.
> 
> On 2/11/21 7:12 PM, Elana Hashman wrote:
>> - When users install Python, it should be easy to install all required
>>   modules for what upstream considers core, including venv, distutils,
>>   and lib2to3.
> 
> I understand that upstream python guys probably think the way to consume
> python stuff is through venv, pip, and setuptools. I have a very
> different view on this, and probably I'm not alone.
> 
> We (Debian people) indeed prefer if our user can enjoy a packaged
> versions of things if they are available (and that's not specific to
> Python). In such a packaged environment, venv and distutils are useless,
> as the distribution is taking care of all what these tools would do
> without apt or dpkg. I do prefer my system to *not* have venv support,
> for example.

This seems to be in contrast to how Python gets used by many many people.
I think it would be nice if up to date packages of all Python software
would exist in Debian but that's clearly not feasible.
Using virtualenvs is expected virtually everywhere where Python is mentioned.

My 2 cents
Michael

[toc] | [prev] | [next] | [standalone]

#13212

[Multipart message — attachments visible in raw view] — view raw

On 2021-02-12 01:11:07 +0100 (+0100), Thomas Goirand wrote:
[...]
> Please do not add distutils, venv and lib2to3 in this python3-full
> metapackage. IMO that's falling into a design that isn't Debian. This
> would probably be best in a "python3-dev-full" or something similar, as
> from the distribution perspective, we see them as developer use only.
> Don't confuse our users so that they install something they don't need.
[...]

I'm failing to see the distinction here. Who are the direct "users"
of the current python3 package if not developers (i.e. those who
would explicitly `apt install python3` on their systems if it
weren't already present)? Any "python3 users" who aren't developers
are getting the python3 package as a dependency of some Python-based
software they're using, they're not going out and installing the
python3 package on their own.

The proposal already indicated that no other packages should declare
dependencies on python3-full anyway, so its only consumers will be
people manually installing it... that is, developers of Python-based
software, or people wanting to run software which isn't packaged in
Debian (which you seem to consider synonymous with being a software
developer for some reason, but I'll go along with it for the sake of
argument).

So it seems like you're saying the people who manually install
python3 will be confused by the presence of python3-full and install
it instead, and accidentally get "software developer tools" when
they do so. But who else is specifically choosing to install a
Python interpreter if not people writing and running non-packaged
Python source?
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#13219

On 12.02.21 01:11, Thomas Goirand wrote:
> I understand that upstream python guys probably think the way to consume
> python stuff is through venv, pip, and setuptools. I have a very
> different view on this, and probably I'm not alone.
> 
> We (Debian people) indeed prefer if our user can enjoy a packaged
> versions of things if they are available (and that's not specific to
> Python). In such a packaged environment, venv and distutils are useless,
> as the distribution is taking care of all what these tools would do
> without apt or dpkg. I do prefer my system to *not* have venv support,
> for example.


Being a Debian Developer myself, I have to disagree here. I *wish* I 
could just install everything via the Debian Packaging System, but the 
reality for most relevant Python packages is very different: packages 
are either outdated or do not exist in Debian -- heck, even PIP is 
outdated in a way that you actually have to `pip install -U pip` in 
order to use it properly due to the recent manylinux change.

So at work, were we use Python, we basically use only Debian's minimal 
image and install a naked Python + pip. Then we upgrade pip to make it 
usable and then install every python package via pip.


Cheers,

Bastian


-- 
Dr. Bastian Venthur                                 https://venthur.de
Debian Developer                                 venthur at debian org

[toc] | [prev] | [next] | [standalone]

#13221

Hi Bastian (2021.02.16_09:17:18_+0000)
> heck, even PIP is outdated in a way that you actually have to `pip
> install -U pip` in order to use it properly due to the recent
> manylinux change.

Hrm, we probably should be backporting support for manylinux2014. Care
to file a bug against pip?

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#13222

[Multipart message — attachments visible in raw view] — view raw

On 2021-02-16 18:24:20 +0000 (+0000), Stefano Rivera wrote:
> Hi Bastian (2021.02.16_09:17:18_+0000)
> > heck, even PIP is outdated in a way that you actually have to `pip
> > install -U pip` in order to use it properly due to the recent
> > manylinux change.
> 
> Hrm, we probably should be backporting support for manylinux2014. Care
> to file a bug against pip?

Unfortunately, ABI 3 support falls into the same category as well.
Lots of projects are now publishing abi3 wheels to cover multiple
interpreter versions instead of separate cp36/cp37/cp38... and newer
pip is needed to be able to deal with that too (at least if you
don't want to have to preinstall an entire build toolchain so you
can install sdists instead).
-- 
Jeremy Stanley

[toc] | [prev] | [next] | [standalone]

#13223 — Python package situation

On 2021-02-16 10:17, Bastian Venthur wrote:
> I *wish* I could
> just install everything via the Debian Packaging System, but the reality for
> most relevant Python packages is very different: packages are either
> outdated or do not exist in Debian

Are you talking about many packages? Or only some, that are
difficult to package? Can you give an example?

At my job, we were always able to stay with Debian packages, or
I just packaged the missing pieces, but maybe our use case is
not that advanced.

I believe, that we don't have much of the Django ecosystem
packaged and many aio* packages seem to be missing...

Cheers

[toc] | [prev] | [next] | [standalone]

#13224 — Re: Python package situation

[Multipart message — attachments visible in raw view] — view raw

On Tue, Feb 16, 2021 at 09:48:05PM +0100, Martin wrote:
> > I *wish* I could
> > just install everything via the Debian Packaging System, but the reality for
> > most relevant Python packages is very different: packages are either
> > outdated or do not exist in Debian
> 
> Are you talking about many packages? Or only some, that are
> difficult to package? Can you give an example?
Are you asking about testing or stable? Because for stable the "packages
are either outdated or do not exist" situation is somewhat expected and
testing is not that interesting case, though even in testing we may have a
lot of outdated packages.

> At my job, we were always able to stay with Debian packages, or
> I just packaged the missing pieces, but maybe our use case is
> not that advanced.
Surely you use only a subset of modules while other people may need a
different subset, and ability to make and upload new or updated packages,
unavailable for most Debian Python users, is definitely helpful.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#13225 — Re: Python package situation

On 2021-02-17 02:13, Andrey Rahmatullin wrote:
> Are you asking about testing or stable? Because for stable the "packages
> are either outdated or do not exist" situation is somewhat expected and
> testing is not that interesting case, though even in testing we may have a
> lot of outdated packages.

At work, we are using stable with backports. Once in a while we
make a local package or local backport, too, and put it in our
local (reprepro driven) repo. Very often, we can just accept the
version in Debian, even if it is not the latest one.

> Surely you use only a subset of modules while other people may need a
> different subset, and ability to make and upload new or updated packages,
> unavailable for most Debian Python users, is definitely helpful.

Yes, having upload rights to Debian, incl. backports, is very
helpful and I was not implying that it were the same situation
for those without that priviledge :-)

But at least people on this ML either have that possibility or
know how to file RFPs/ITPs or just ask the right people.

But that option is less attractive, if the work is far too much,
i.e. either too many packages involved or very tricky packages -
for technical or other reasons.

That's why I'm curious: Maybe the missing packages are the same
for multiple people and we can solve the problem?

[toc] | [prev] | [next] | [standalone]

#13226 — Re: Python package situation

Andrey Rahmatullin <wrar@debian.org> writes:

> On Tue, Feb 16, 2021 at 09:48:05PM +0100, Martin wrote:
> Are you asking about testing or stable? Because for stable the "packages
> are either outdated or do not exist" situation is somewhat expected and
> testing is not that interesting case, though even in testing we may have a
> lot of outdated packages.

I believe there are a number of Python packages in Debian unstable that
are out of date in respect to latest upstream.

e.g.

https://qa.debian.org/developer.php?login=bam%40debian.org&comaint=yes

Somebody needs to do the work to update them. But maybe the fact that
nobody is doing so, might mean that nobody is using them?

The packages which are up-to-date have not been updated by upstream in a
long time, and this isn't necessarily a good thing either.

I personally found a while back that keeping these packages up-to-date
was draining far too much of my time. Time I don't actually have. So I
now use Docker+pip for my applications.

Plus upgrading system packages to fix dependencies always made me
worried I might break something unrelated that I couldn't or wasn't
ready to fix. So most of the time I don't use these packages anymore.

Yes, the idea of the packages being stable in Debian stable, and hence,
won't break anything until you do a release upgrade is a good one. But
if you encounter a bug/missing feature in such a package that breaks
your application, often the only real alternative is to use the latest
version. Often only the latest version is supported by upstream also.
-- 
Brian May <bam@debian.org>

[toc] | [prev] | [next] | [standalone]

#13227 — Re: Python package situation

[Multipart message — attachments visible in raw view] — view raw

On Wed, Feb 17, 2021 at 11:51:52AM +1100, Brian May wrote:
> I believe there are a number of Python packages in Debian unstable that
> are out of date in respect to latest upstream.
> 
> e.g.
> 
> https://qa.debian.org/developer.php?login=bam%40debian.org&comaint=yes
> 
> Somebody needs to do the work to update them. But maybe the fact that
> nobody is doing so, might mean that nobody is using them?
And/or nobody who uses them is able to update them in Debian or at least
report a bug, and/or it's easier to install them directly than update them
in Debian and install from there.
Also note that many Python module packages in Debian have very low popcon.

-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#13228 — Re: Python package situation

Hi,

On Wed, 17 Feb 2021, Brian May wrote:
> I believe there are a number of Python packages in Debian unstable that
> are out of date in respect to latest upstream.
> 
> e.g.
> https://qa.debian.org/developer.php?login=bam%40debian.org&comaint=yes
> 
> Somebody needs to do the work to update them. But maybe the fact that
> nobody is doing so, might mean that nobody is using them?

Quite often, we introduce Python packages for the need of a specific
application and then we don't really see a benefit to upgrade the package
unless the application also needs a newer version of the module.

That likely explains partly why so many modules are lagging behind.

> I personally found a while back that keeping these packages up-to-date
> was draining far too much of my time. Time I don't actually have. So I
> now use Docker+pip for my applications.

On the Kali side, I'm trying to work with Jelmer and his janitor bot to
try to automate as much as possible the work of preparing new upstream
releases. We're getting close to having something useful where the bot
does at least the upstream tarball import and a test rebuild and so on.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@debian.org>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.maint.python

csiph-web