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 1 of 2  [1] 2  Next page →

#13192 — upstream python concerns, python3-full package for bullseye

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

[BCC steering-council@python.org]

Some issues were raised to me privately by individual upstream Python
maintainers about the user experience of Python in Debian, focused on
confusion caused by the split of CPython into a number of smaller
packages.

I have spoken with the Python Steering Council and met with Matthias and
Stefano to discuss what issues we can feasibly fix in Debian in time for
the bullseye release.

Agreed amongst the three of us:

- An issue was raised about distutils, considered core functionality of
  the language, being split off the core Python package. We can't change
  the distutils package split in time for bullseye, as we are in freeze
  and this change would be disruptive.
- It was requested that we differentiate between "system" Python and
  what upstream considers core Python. A package rename (e.g. python3 ->
  python3-system) will confuse everyone and take multiple releases to
  implement, and cannot be targeted until bookworm at the earliest.
- When users install Python, it should be easy to install all required
  modules for what upstream considers core, including venv, distutils,
  and lib2to3. I propose that we add a python3-full* metapackage for
  bullseye. (*We can use a different name, but it must be a name not
  currently in use.)

Actions: 

- Stefano: Update python-policy to describe "python3-full".
- Matthias: Prepare new "python3.9-full" and "python3-full" packages for
  Debian and make sure these can be shipped in bullseye.
- Matthias: Proposing to backport "python3-full" packages to buster and
  Ubuntu LTSes.
- Elana: Request a "distros roundtable" at the upcoming PyCon to
  facilitate longer-term discussions with distributions who package and
  build Python.

If you have any questions, please feel free to reach out to me or
discuss on this thread. (I'm not normally subscribed to debian-python@
so please CC me.)

- e

[toc] | [next] | [standalone]

#13193

Hi Elana (2021.02.11_18:12:34_+0000)
> - Stefano: Update python-policy to describe "python3-full".

I have prepared a policy MR for this:
https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/8
It catches up on the current split situation, too.

diff --git a/debian/python-policy.dbk b/debian/python-policy.dbk
index 875b281..8b67f4a 100644
--- a/debian/python-policy.dbk
+++ b/debian/python-policy.dbk
@@ -233,17 +233,28 @@
 	  some exceptions.
 	</para>
 	<para>
-	  Excluded are modules that cannot be included for licensing reasons
-	  (for example the <literal>profile</literal> module), for dependency tracking
-	  purposes (for example the GPL-licensed <literal>gdbm</literal> module), or
-	  that should not be included for packaging reasons (for example
-	  the <literal>tk</literal> module which depends on Xorg).
+	  Excluded are modules that cannot be included for licensing reasons,
+	  for dependency tracking purposes (for example the GPL-licensed
+	  <literal>gdbm</literal> module), or that should not be included
+	  for packaging reasons (for example the <literal>tk</literal>
+	  module which depends on Xorg and the <literal>venv</literal>
+	  module which depends on wheels to bootstrap pip).
+	  Modules that would interfere with system package management (for example
+	  <literal>ensurepip</literal>, when used outside virtual environments) are
+	  modified to print a message explaining the problem and recommending
+	  alternatives.
 	</para>
 	<para>
 	  Some tools and files for the <emphasis>development</emphasis> of Python
 	  modules are split off in a separate binary package
 	  <literal>python<replaceable>X</replaceable>.<replaceable>Y</replaceable>-dev</literal>.
 	</para>
+	<para>
+	  Modules only used for <emphasis>building</emphasis> of Python modules
+	  (e.g. <literal>distutils</literal> and <literal>lib2to3</literal>) are
+	  split into separate packages.
+	  The <literal>python3-venv</literal> binary package depends on these.
+	</para>
 	<para>
 	  Documentation will be provided separately as well.
 	</para>
@@ -255,6 +266,15 @@
 	  the <literal>python3.<replaceable>Y</replaceable></literal> package that installs
 	  the executable.
 	</para>
+	<para>
+	  A <literal>python3-full</literal> binary package must ensure that the
+	  entire Python standard library is available, including all modules
+	  split into separate packages (but excluding modules excluded from
+	  Debian for licensing reasons).
+	  This package exists for the convenience of python developers, and
+	  must not be used in dependencies by python module or application
+	  packages.
+	</para>
 	<para>
 	  The version of the <literal>python3</literal> package must be
 	  greater than or equal to 3.<replaceable>Y</replaceable> and lower than

SR

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

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

#13218

Hi debian-python (2021.02.11_18:24:57_+0000)
> I have prepared a policy MR for this:
> https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/8
> It catches up on the current split situation, too.

We had a discussion on the principle of the change, but nobody has
responded to the policy wording yet.

Anyone seconds / objections?

SR

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

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

#13220

On 2/16/21 5:25 AM, Stefano Rivera wrote:
> Hi debian-python (2021.02.11_18:24:57_+0000)
>> I have prepared a policy MR for this:
>> https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/8
>> It catches up on the current split situation, too.
> 
> We had a discussion on the principle of the change, but nobody has
> responded to the policy wording yet.
> 
> Anyone seconds / objections?
> 
> SR
> 

It's fine, thanks for working on this.

Cheers,

Thomas Goirand (zigo)

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

#13194

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.

So indeed, it's a good thing to *not* include distutils and venv by
default when someone installs python.

As for lib2to3, is this a joke? Lib2to3 is a complete failure to begin
with. Upstream python developer naively thought everyone would just
switch at once to Python3, but it never happened, which is why things
like six exist (ie: to bring a layer of compatibility between python 2
and 3 during the transition).
Also, since we got rid of Python 2, is this a (naive) call to bring a
library that could convert old code which nobody cared to port in time?
This also will be a failure, IMO. Lib2to3 is just an utility, which has
nothing to do on a standard user computer, unless they really know what
it does and explicitly want to use it (and in that case, it's easy for
them to fetch it).

> I propose that we add a python3-full* metapackage for
>   bullseye. (*We can use a different name, but it must be a name not
>   currently in use.)

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.

Hoping that what I wrote is making sense,
Cheers,

Thomas Goirand (zigo)

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

#13195

Hi Thomas (2021.02.12_00:11:07_+0000)
> So indeed, it's a good thing to *not* include distutils and venv by
> default when someone installs python.

...

> > I propose that we add a python3-full* metapackage for
> >   bullseye. (*We can use a different name, but it must be a name not
> >   currently in use.)
> 
> 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.

From your arguments above, it doesn't sound like the python3-full solves
a problem you experience. So, I'm not sure why you'd be using it.

If it doesn't include distutils, venv, lib2to3, etc. then it doesn't
solve any problem we currently have, and we don't need it. The purpose
is to provide a package that gives you the entire stdlib.

SR

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

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

#13197

On 2/12/21 1:42 AM, stefanor@debian.org wrote:
> Hi Thomas (2021.02.12_00:11:07_+0000)
>> So indeed, it's a good thing to *not* include distutils and venv by
>> default when someone installs python.
> 
> ...
> 
>>> I propose that we add a python3-full* metapackage for
>>>   bullseye. (*We can use a different name, but it must be a name not
>>>   currently in use.)
>>
>> 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.
> 
> From your arguments above, it doesn't sound like the python3-full solves
> a problem you experience. So, I'm not sure why you'd be using it.

I don't think I would. And to me, Python is already "full"(y supported)
without these. Though at least, adding "dev" in its name shows it's not
for our users.

> If it doesn't include distutils, venv, lib2to3, etc. then it doesn't
> solve any problem we currently have, and we don't need it. The purpose
> is to provide a package that gives you the entire stdlib.
> 
> SR

What I read from Elana, is that *upstream* think we have a problem. But
do we really have one? Or are we just being influenced by upstream who
is trying to impose a view we don't necessary share?

Cheers,

Thomas Goirand (zigo)

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

#13198

On Fri, 12 Feb 2021, Thomas Goirand wrote:
> What I read from Elana, is that *upstream* think we have a problem. But
> do we really have one? Or are we just being influenced by upstream who
> is trying to impose a view we don't necessary share?

Or is it you that is trying to impose your view on those users?

Let's be clear, I understand what you are saying and I mostly agree
with your view but Debian is about inclusiveness and about meeting
the needs of as many people as possible and I believe that implementing
this python3-full meta-package can only help towards this.

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] | [next] | [standalone]

#13199

Hi,

Looks like once more I've been not able to express myself clearly enough
in the first message. Hopefully, what's bellow contain *all* of my
thoughts, and that it brings value to this thread.

On 2/12/21 9:30 AM, Raphael Hertzog wrote:
> On Fri, 12 Feb 2021, Thomas Goirand wrote:
>> What I read from Elana, is that *upstream* think we have a problem. But
>> do we really have one? Or are we just being influenced by upstream who
>> is trying to impose a view we don't necessary share?
> 
> Or is it you that is trying to impose your view on those users?
> 
> Let's be clear, I understand what you are saying and I mostly agree
> with your view but Debian is about inclusiveness and about meeting
> the needs of as many people as possible and I believe that implementing
> this python3-full meta-package can only help towards this.

I mostly agree to add a metapackage. I just don't agree with the choice
of package name. It makes our user believe that Python isn't "full"
without it, and they then may install it when they don't need it to
consume whatever is packaged in Debian. Reality is different.

Also, it's a disservice to push our users into the direction of using
venv which is very ugly way to use Python in a Debian system, outside of
just testing something. You then end up with a variety of versions of
things pulled by pip, which are quickly unmanageable. That's why we do
package Python modules, and make sure they work well together
(sometimes, patching them to achieve this goal).

So, by all means, let's create a metapackage, and call it
"python3-addons-that-upstream-thinks-make-python-full" or anything you
like, but not just "python3-without-this-package-python-is-not-full",
misguiding our users to install venv and distutils which they don't need
if they are consuming only Python for things that we package already.

I'm also concerned that this is useful at all. If someone wants to use
venv, 2to3 or setuptools, I believe they will know how to fetch them...

Cheers,

Thomas Goirand (zigo)

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

#13203

On 2021-02-12 10:16, Thomas Goirand wrote:
> I mostly agree to add a metapackage. I just don't agree with the choice
> of package name. It makes our user believe that Python isn't "full"
> without it, and they then may install it when they don't need it to
> consume whatever is packaged in Debian. Reality is different.

I agree with your technical point of view. Friends don't let
friends use pip and I banned its use at work.

I don't care about having the package or not and how it were
named, as long as it remains easy to not have it.

Cheers

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

#13206

On 12.02.21 10:16, Thomas Goirand wrote:
> I mostly agree to add a metapackage. I just don't agree with the choice
> of package name. It makes our user believe that Python isn't "full"
> without it

I think you are reading waaay too much into just this name. The package
will also have a synopsis and a description. There's no reason for our
users to assume or believe anything at all; the facts will be right
there in front of them.

And there's no way past the synopsis with some generic name like
python3-full, or python3-minimal, or python3-dev, etc.

> Also, it's a disservice to push our users into the direction of using
> venv which is very ugly way to use Python in a Debian system, outside of
> just testing something.

How would merely having these packages installed push a user to do
anything with them?

Furthermore, I think "just testing something" is a major use case we
absolutely should support. Personally, it's the first step in my process
for packaging something for Debian, because some things are better kept
out, as I'm sure we've all made the experience.

And finally, let's face it: for the vast amount of users and even
upstreams(!), we wouldn't be pushing them towards venv, they are already
there. pip (and conda) are already the standard tools for getting Python
packages. I don't see how standing in the way of this will win us any
favors. On the contrary, I do see how this casts a unfavorable light on us.

Best,
Christian

PS: To be clear, personally, I vastly prefer Debian-packaged Python
software, and will package anything I use if it is not yet in the
archive, provided its quality is sufficiently high and there is
continued upstream support.

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

#13207

Hi,

As far as I understand, the divergence between "Python upstream" and 
Debian is:

- It looks like Debian target users consuming software, users just 
install a package and it works, no venv needed obviously, it always just 
work, it's fantastic. Users may not even care if the program is written 
in Python or not at this point.

- Upstream Python is obviously composed by people writing in Python and 
know many people who write some Python too: all in need of venv to work.

> Also, it's a disservice to push our users into the direction of using
> venv which is very ugly way to use Python in a Debian system
I do agree, we could even replace Python with software in this sentence.

And I don't think we're pushing our users to always install things in 
venvs. Providing venv is not a big signal for Debian users to ask them 
to use it to install packages (if a signal at all).

With my "I do write things in Python that may run on non-Debian systems" 
hat, and "I teach Python" (most of them not using Debian) hat, a venv is 
helping me in many many ways, it's literally part of my daily routine:

- It allows me to pin a set of dependencies and sub-dependencies to an 
exact version (I do use pip-compile, from pip-tools), per project, that 
I can use in automatic tests (ensuring if tests passes today, they'll 
pass tomorrow), I can share this set with coworkers and future me ("if 
it works for me, it works for you"), note my coworkers may not use 
Debian at all.

- It allows me to easily replace a dependency with a modified one to 
test it, or make anyone else test it (for example [1]).

- It allows me to work on my Debian testing laptop on code aimed to work 
on Debian stable, or a completly different OS.

- It allows me to work on various projects with a different set of 
incompatible dependencies.

So while I do agree that a *normal user* does not need a venv as I 
myself appreciate, as a user, how fantastic it is to be able to install 
a software using Debian packages, I still think venv is a very usefull 
tool that I'm very happy to have in the Python stdlib and use daily.

(My current use of Python on Debian is: compile it myself, I need 
multiple versions of Python for test purposes anyway.)

[1]: https://github.com/PyCQA/pylint/pull/3890#issuecomment-727591305

P.S.: If you still feel I'm completly wrong to use venv and pip in my 
workflow, I'll be very happy to learn better ways.
-- 
[Julien Palard](https://mdk.fr)

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

#13211

On 2/12/21 2:08 PM, Julien Palard wrote:
> Hi,
> 
> As far as I understand, the divergence between "Python upstream" and 
> Debian is:
> 
> - It looks like Debian target users consuming software, users just 
> install a package and it works, no venv needed obviously, it always just 
> work, it's fantastic. Users may not even care if the program is written 
> in Python or not at this point.
> 
> - Upstream Python is obviously composed by people writing in Python and 
> know many people who write some Python too: all in need of venv to work.

Yes, I think that's a good summary for the user's view. But keep in mind, that
when "upstream" is speaking about the "user" experience of Python on Debian,
they usually mean the developer experience.

> So while I do agree that a *normal user* does not need a venv as I 
> myself appreciate, as a user, how fantastic it is to be able to install 
> a software using Debian packages, I still think venv is a very usefull 
> tool that I'm very happy to have in the Python stdlib and use daily.

Debian itself uses venv in build tests and in autopkg tests. So we also need a
working venv, and we ship it.  If something is broken with setting up a venv, we
should fix it.

What is less seen by "Python upstream" is that recommended upstream practices
like CPython defaulting to site-packages by default until recently (sudo python3
setup.py install), or sudo pip install|upgrade do break the user's system.
Compare that with safe approaches like autoconf defaulting to /usr/local
installs.  Let me say that "Python upstream" is not always enthusiastic to
acknowledge these issues.

There also seems to be some level of frustration of "Python upstream" supporting
users using Python on Debian on upstream communication channels like #python on
Freenode.  Yes, I have heard the complaints, but usually things are not
forwarded to Debian.  Stefano and myself have recently joined #python, so let's
see if that can help.

Matthias

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

#13217

Hi,

FYI, my concerned are addressed by what Stefano wrote about the full
desc, though I still feel like I need to reply to you.

On 2/12/21 2:08 PM, Julien Palard wrote:
> Hi,
> 
> As far as I understand, the divergence between "Python upstream" and 
> Debian is:
> 
> - It looks like Debian target users consuming software, users just 
> install a package and it works, no venv needed obviously, it always just 
> work, it's fantastic. Users may not even care if the program is written 
> in Python or not at this point.
> 
> - Upstream Python is obviously composed by people writing in Python and 
> know many people who write some Python too: all in need of venv to work.
> 
>> Also, it's a disservice to push our users into the direction of using
>> venv which is very ugly way to use Python in a Debian system
> I do agree, we could even replace Python with software in this sentence.
> 
> And I don't think we're pushing our users to always install things in 
> venvs. Providing venv is not a big signal for Debian users to ask them 
> to use it to install packages (if a signal at all).
> 
> With my "I do write things in Python that may run on non-Debian systems" 
> hat, and "I teach Python" (most of them not using Debian) hat, a venv is 
> helping me in many many ways, it's literally part of my daily routine:
> 
> - It allows me to pin a set of dependencies and sub-dependencies to an 
> exact version (I do use pip-compile, from pip-tools), per project, that 
> I can use in automatic tests (ensuring if tests passes today, they'll 
> pass tomorrow), I can share this set with coworkers and future me ("if 
> it works for me, it works for you"), note my coworkers may not use 
> Debian at all.
> 
> - It allows me to easily replace a dependency with a modified one to 
> test it, or make anyone else test it (for example [1]).
> 
> - It allows me to work on my Debian testing laptop on code aimed to work 
> on Debian stable, or a completly different OS.
> 
> - It allows me to work on various projects with a different set of 
> incompatible dependencies.

Wouldn't it be nicer if all of the dependencies you're talking about
were all playing well together? You're happy with venv and pip because
they address the huge problem that your dependencies are constantly
breaking the world. This needs to stop. Promoting venv and pip isn't
helping toward this goal, and that's what I was trying to say to begin with.

> I still think venv is a very usefull tool

It is. Because it addresses (badly) the brokenness of your dependencies,
as I wrote above.

> P.S.: If you still feel I'm completly wrong to use venv and pip in my
> workflow, I'll be very happy to learn better ways.

You are not. Though in an ideal world, you'd be only describing the list
of dependency you need, and the tooling would either fetch the Debian
package (if available) or through PyPi, and it would always work,
without ever needing to care about versions (here, from your side, with
pinning and version bounds), and without ever needing to isolate things
in a venv/chroot.

Cheers,

Thomas Goirand (zigo)

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

#13214

Hi Thomas (2021.02.12_09:16:28_+0000)

I should have combined this reply with my previous one, but it didn't
thread there cleanly:

> I mostly agree to add a metapackage. I just don't agree with the choice
> of package name. It makes our user believe that Python isn't "full"
> without it, and they then may install it when they don't need it to
> consume whatever is packaged in Debian. Reality is different.

The reality is that you're conflating two statements there:
1. Python isn't "full" without it.
2. Users may believe that they need this to run things that are
   packaged in Debian.

I'd say 1 is true, but users believing 2 would be incorrect. As I said
in my other mail, I hope this can be dealt with in the description. And
there's certainly no harm in users making this mistake, beyond
installing unnecessary junk.

We split the Python standard library up into multiple binary packages,
for a variety of reasons, and when you install python3, you don't get it
all. Developers outside of Debian's sphere of influence won't appreciate
those splits and software they write won't be expecting them. We can
deal with this within Debian, but not when users install 3rd party
software directly.

While we may have the goal of packaging all useful software in Debian,
the reality is that this is only ever a goal, constantly unachievable.
We serve our users better when we make it easy to extend beyond Debian.

SR

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

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

#13213

Hi Thomas (2021.02.12_08:10:51_+0000)
> > From your arguments above, it doesn't sound like the python3-full solves
> > a problem you experience. So, I'm not sure why you'd be using it.
> 
> I don't think I would. And to me, Python is already "full"(y supported)
> without these. Though at least, adding "dev" in its name shows it's not
> for our users.

Yeah, I can see the argument for calling this python3-full-dev.

On the flip side, in debian packaging, -dev implies C headers, and this
is more than that.

I think this would also be dealt with in the package description, I'd
imagine something like:

 Python, the high-level, interactive object oriented language,
 includes an extensive class library with lots of goodies for
 network programming, system administration, sounds and graphics.
 .
 This package is a dependency package, which depends on the full
 standard library of Python for Python developers. Including modules
 used only at build-time, such as venv and distutils, and modules with
 complex dependencies, such as tk and IDLE.
 .
 This package depends on Debian's default python 3 version's full
 standard library (currently v3.9).

BTW, I noticed some other vague descriptions while I was writing this
example description. Fixed:
https://salsa.debian.org/cpython-team/python3-defaults/-/commit/d1430d009688b9affcfa3b95ffcba4dcdcaf33ff

SR

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

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

#13215

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

Hi all,

Am 12.02.21 um 20:52 schrieb Stefano Rivera:
>  This package is a dependency package, which depends on the full
>  standard library of Python for Python developers. Including modules
>  used only at build-time, such as venv and distutils, and modules with
>  complex dependencies, such as tk and IDLE.

Tk and Idle would belong into a hypothetical python3-extra, I guess.
This is the first time they're mentioned here, at least as far as my 
searching skills show.

Bye
Michael

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

#13200

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

On Fri, 12 Feb 2021 at 02:43, <stefanor@debian.org> wrote:

> From your arguments above, it doesn't sound like the python3-full solves
> a problem you experience. So, I'm not sure why you'd be using it.
>
> If it doesn't include distutils, venv, lib2to3, etc. then it doesn't
> solve any problem we currently have, and we don't need it. The purpose
> is to provide a package that gives you the entire stdlib.
>

I wanted to point out that this follows the pattern set by the many other
*-full packages in Debian, such as ruby-full.

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

#13201

On Fri, Feb 12, 2021 at 11:08:14AM +0200, Tristan Seligmann wrote:
> I wanted to point out that this follows the pattern set by the many other
> *-full packages in Debian, such as ruby-full.

Perhaps python3-core would be more appropriate, and python3-full can be
left for something even bigger.

Some examples:

collectd-core - statistics collection and monitoring daemon (core system)
gnome-core - GNOME Desktop Environment -- essential components
nginx-core - nginx web/proxy server (standard version)
ros-core - Robot OS core metapackage
syslog-ng-core - Enhanced system logging daemon (core)
xserver-xorg-core - Xorg X server - core server

-- 
Valentin

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

#13204

On 2021/02/12 11:40, Valentin Vidic wrote:
> Perhaps python3-core would be more appropriate, and python3-full can be
> left for something even bigger.

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.

-Jonathan

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web