[Distutils] Re: Setuptools adopts distutils

istutils.spawn.find_executable. From my point of view it doesn't make sense to replace a bad usage with another bad usage. Maybe it's worth to mention the distutils deprecation for 3.10 already in 3.9, so people will have more time to adopt. Matthias > > Best, > Paul > > On 7/13/20 9:57

[Distutils] Re: Setuptools adopts distutils

On 7/3/20 5:18 PM, Jason R. Coombs wrote: > I’m pleased to announce the release of Setuptools 48, which adopts the > distutils codebase from CPython per > pypa/setuptools#417 and >

[Distutils] Re: Idea: perennial manylinux tag

On 30.11.18 19:10, Brett Cannon wrote: > I think either approach works, but if we do go with a glibc-versioned tag > that we make it explicit in the tag, e.g. `manylinux_glibc_{version}`. That > way if we ever choose to support musl (for Alpine) we can. > > The one question I do have is how the

[Distutils] Re: sudo pip install: install pip files into /usr/local on Linux?

On 26.05.2018 14:59, Nick Coghlan wrote: > On Sat., 26 May 2018, 4:25 am Donald Stufft, wrote: > >> >> >> On May 25, 2018, at 12:44 PM, Thomas Kluyver wrote: >> >> It's more annoying for scripts - on common Linux distributions, the user >> scripts location ~/.local/bin is not on PATH by

Re: [Distutils] Extracting distutils into setuptools

On 27.09.2017 11:37, Nick Coghlan wrote: > On 27 September 2017 at 12:30, xoviat wrote: >>> In short, I think your proposal is a good one, but how can we allocate >>> manpower? >> >> (issue31595 on bugs.python.org) >> >> So what do others think of this? My sense of things is

Re: [Distutils] PEP 517: Bootstrapping setuptools

On 22.08.2017 15:23, Daniel Holth wrote: > You kindof need pkg-resources as a separate package for this. It is a cool > parlor trick but it's simpler and harmless to just always install > setuptools like we do. when will we have a split out pkg-resources?

Re: [Distutils] reproducible builds

On 17.03.2017 18:19, Robin Becker wrote: > An issue has been raised for reportlab to support a specific environment > variable namely SOURCE_DATE_EPOCH. The intent is that we should get our time > from this variable rather than time.localtime(time.time()) so that produced > documents are more

Re: [Distutils] PEP for specifying build dependencies

On 11.05.2016 02:39, Brett Cannon wrote: Donald, Nathaniel, and I have finished our proposed PEP for specifying a projects' build dependencies. The PEP is being kept at https://github.com/brettcannon/build-deps-pep, so if you find spelling mistakes and grammatical errors please feel free to send

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On 16.02.2016 15:43, David Cournapeau wrote: On Tue, Feb 16, 2016 at 11:05 AM, Matthias Klose <d...@ubuntu.com> wrote: On 02.02.2016 02:35, Glyph Lefkowitz wrote: On Feb 1, 2016, at 3:37 PM, Matthias Klose <d...@ubuntu.com> wrote: On 30.01.2016 00:29, Nathaniel Smith wrote:

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On 16.02.2016 15:20, Paul Moore wrote: On 16 February 2016 at 14:14, Wayne Werner wrote: I've learned that *usually* linux distro repos lag way behind in updating their Python packages, so unless I *can't* install the package via pip, that's what I do. that's how

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On 02.02.2016 02:35, Glyph Lefkowitz wrote: On Feb 1, 2016, at 3:37 PM, Matthias Klose <d...@ubuntu.com> wrote: On 30.01.2016 00:29, Nathaniel Smith wrote: Hi all, I think this is ready for pronouncement now -- thanks to everyone for all their feedback over the last few weeks! I

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On 02.02.2016 01:30, Donald Stufft wrote: On Feb 1, 2016, at 6:37 PM, Matthias Klose <d...@ubuntu.com> wrote: On 30.01.2016 00:29, Nathaniel Smith wrote: Hi all, I think this is ready for pronouncement now -- thanks to everyone for all their feedback over the last few weeks! I don't

Re: [Distutils] [final version?] PEP 513 - A Platform Tag for Portable Linux Built Distributions

On 30.01.2016 00:29, Nathaniel Smith wrote: Hi all, I think this is ready for pronouncement now -- thanks to everyone for all their feedback over the last few weeks! I don't think so. I am biased because I'm the maintainer for Python in Debian/Ubuntu. So I would like to have some feedback

Re: [Distutils] draft PEP: manylinux1

On 21.01.2016 17:13, Nathaniel Smith wrote: On Jan 21, 2016 2:07 AM, "M.-A. Lemburg" wrote: On 21.01.2016 10:31, Nick Coghlan wrote: On 21 January 2016 at 19:03, M.-A. Lemburg wrote: By using the version based approach, we'd not run into this problem and

Re: [Distutils] draft PEP: manylinux1

On 21.01.2016 04:55, Nathaniel Smith wrote: the choice of compiler is questionable. Just a pick into a release series. Not even the last released version on this release series. Is this a good choice? Maybe for x86_64 and i386, but not for anything else. The permitted external shared

Re: [Distutils] depending on setuptools is discouraged?

Am 23.10.2014 um 22:38 schrieb Donald Stufft: On Oct 23, 2014, at 4:23 PM, Michael Merickel m...@m.merickel.org wrote: I'm noticing a trend that depending on setuptools is discouraged[1] in the install_requires of your setup.py. However, some packages like pyramid have core features that

Re: [Distutils] Packaging meetup @ EuroPython 2014

Am 21.07.2014 14:09, schrieb Richard Jones: I've set the time for the packaging meetup to 11:00 this Thursday. There is currently no meeting room available for such a gathering, so we'll just meet outside in the garden. hi, I'll be there if I can get in (not attending EuroPython myself).

Re: [Distutils] Expectations on how pip needs to change for Python 3.4

Am 13.07.2013 16:54, schrieb Paul Moore: 1. Install to user-packages by default. 2. Not depend on setuptools (??? - Nick's inversion idea) 3. Possibly change the wrapper command name from pip to pip3 on Unix. 4. Ensure that pip upgrading itself in-place is sufficiently robust and reliable

Re: [Distutils] distlib updated - comments sought

On 05.10.2012 19:24, Paul Moore wrote: On 5 October 2012 17:04, Daniel Holth dho...@gmail.com wrote: ~1300 of the ~2 packages on pypi have trouble using setup.py as their build system / metadata source format. That's interesting information. Do you know in what way they have trouble

Re: [Distutils] PEP proposal: multi-interpreter naming convention for built distributions

On 06.08.2012 23:09, Daniel Holth wrote: I propose a three-part Implementation, ABI, Architecture naming scheme for built distributions as a new Python standard. The full list of allowed tags would need to be fleshed out for this to be completed, but I don't know enough about the needs of each

Re: [Distutils] zc.buildout fails to use system-installed dep?

On 10.12.2010 13:42, Brian Sutherland wrote: The current method using dpkg-divert is not too bad, more packages than python-zope.interface could include that file as well. So you don't force installation of python-zope.interface. It also uses standard dpkg functionality, which is a robustness

Re: [Distutils] GCC versions and binary egg names

On 26.07.2010 19:04, Chris Withers wrote: Hi All, In addition to the UCS2/4 problems already described by MAL and which I've bumped into myself, I now have a problem with binary linux eggs where the GCC version doesn't match that of the system the egg is being installed on. why would this be

Re: [Distutils] [Python-Dev] request for comments - standardization of python's purelib and platlib

On 14.08.2009 10:02, Tarek Ziadé wrote: On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannonbr...@python.org wrote: On Thu, Aug 13, 2009 at 11:23, Jan Matejekjan.mate...@novell.com wrote: Hello, I'm cross-posting this to distributi...@freedesktop and python-dev, because the topic is relevant to

Re: [Distutils] Buildout recipe for managing .deb packages?

Kent Tenney schrieb: On Thu, Apr 9, 2009 at 2:38 PM, Jim Fulton j...@zope.com wrote: On Apr 9, 2009, at 3:37 PM, Kent Tenney wrote: Howdy, Is there a recommended way to manage Debian system packages with a buildout? I can't imagine why you would want to. I probably don't know what you're

Re: [Distutils] [pyconuk] just use debian

zooko writes: On Sep 24, 2008, at 14:47 PM, Marius Gedminas wrote: On Tue, Sep 23, 2008 at 09:24:00PM -0700, Kevin Teague wrote: Or they can just use debian! Any debian developers out there up for the task of packaging up the 1500+ odd packages released from the Zope community?

Re: [Distutils] Annoucing distribute project

announcing a fork without any objective? what is this fork about? if it stays 100% compatible, isn't it just more frequent releases? Matthias Tarek Ziadé writes: Hi, I am launching a fork of setuptools. The name is Distribute. (not definitive) and will be community-driven This fork

Re: [Distutils] Python Package Management Sucks

Chris Withers writes: (I'll be CC'ing the distutils sig in to these replies as this discussion probably belongs there...) Nicolas Chauvat wrote: The slides for my two talks can be found here: http://www.simplistix.co.uk/presentations Python Package Management Sucks Install

Re: [Distutils] [Python-Dev] Capsule Summary of Some Packaging/Deployment Technology Concerns

Jeff Rush writes: I was in a Packaging BoF yesterday and, although not very relevant to the packager bootstrap thread, Guido has asked me to post some of the concerns. We did address many topics on both days, I added the following topics which were addressed on the Friday BoF only, see

Re: [Distutils] [Python-Dev] Capsule Summary of Some Packaging/Deployment Technology Concerns

Phillip J. Eby writes: 7. Many wanted to ability to install files anywhere in the install tree and not just under the Python package. Under distutils this was possible but it was removed in setuptools for security reasons. It wasn't security, it was manageability. Egg-based

Re: [Distutils] setuptools - what if a library is required but is in the standard lib?

zooko writes: On Feb 7, 2008, at 11:38 AM, Phillip J. Eby wrote: Only if someone messed with Python's default build structure. The Python stdlib should contain an .egg-info file marking the presence of wsgiref 0.1.2. Some Linux distributions may remove this file due to a

[Distutils] setuptools -- passing options to subcommands?

I'd like to omit the python version in the .egg-info directory name when using the --single-version-externally-managed option. In this case I know that the module is installed in a patch specific to the python version. How can this option be propagated to the subcommands 'install_egg_info' and

Re: [Distutils] setuptools -- passing options to subcommands?

Phillip J. Eby writes: At 03:51 PM 11/2/2007 +0100, Matthias Klose wrote: I'd like to omit the python version in the .egg-info directory name when using the --single-version-externally-managed option. In this case I know that the module is installed in a patch specific to the python version

Re: [Distutils] python version information in .egg-info directory name

Phillip J. Eby writes: Unfortunately, Debian's policy -- especially the idea of mixing paths for multiple Python versions -- doesn't mesh well with reality. that's a misunderstading, we don't do that. common files are shipped in one location outside of sys.path and linked to a version specific