On 2021-02-16 18:24:20 + (+), Stefano Rivera wrote:
> Hi Bastian (2021.02.16_09:17:18_+)
> > 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 backpor
Hi Bastian (2021.02.16_09:17:18_+)
> 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
--
On 2/16/21 5:25 AM, Stefano Rivera wrote:
> Hi debian-python (2021.02.11_18:24:57_+)
>> 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 princi
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
Hi debian-python (2021.02.11_18:24:57_+)
> 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
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
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 t
Hi Thomas (2021.02.12_09:16:28_+)
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
Hi Thomas (2021.02.12_08:10:51_+)
> > 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, add
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 distrib
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 fa
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 ma
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 p
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
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 writte
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 an
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 maintaini
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
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.
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 Pyth
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.
So
On Fri, 12 Feb 2021 at 02:43, 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 w
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
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 th
On 2/12/21 1:42 AM, stefa...@debian.org wrote:
> Hi Thomas (2021.02.12_00:11:07_+)
>> 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
Hi Thomas (2021.02.12_00:11:07_+)
> 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
> > currentl
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 up
Hi Elana (2021.02.11_18:12:34_+)
> - 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.d
[BCC steering-coun...@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
29 matches
Mail list logo
