[Distutils] Re: Setuptools adopts distutils

e just replaced by setuptools._distutils.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 > >

[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 > pypa/packaging-problems#127

[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 co

[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 default.

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 that people are open >

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 invar

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 wrote: On 02.02.2016 02:35, Glyph Lefkowitz wrote: On Feb 1, 2016, at 3:37 PM, Matthias Klose wrote: On 30.01.2016 00:29, Nathaniel Smith wrote: Hi all, I think this is ready for

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 distros work. They provide a

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 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 think so.

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

On 10.02.2016 21:26, Donald Stufft wrote: On Feb 10, 2016, at 3:18 PM, Matthias Klose wrote: But then why call it manylinux instead of centos5? You build it on this OS, you expect others to build it on this OS. just name it what it is. Because this is a very specific subset of CentOS 5

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 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 think so. I am b

Re: [Distutils] Does anyone understand what's going on with libpython on Linux?

On 07.02.2016 13:38, Antoine Pitrou wrote: On Sun, 7 Feb 2016 00:25:57 -0800 "Robert T. McGibbon" wrote: What are Debian/Ubuntu doing in distutils so that extensions don't link to libpython by default? I don't know exactly, but one way to reproduce this is simply to build the interpreter with

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 f

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 libra

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 gain a lot more. I think it's bett

Re: [Distutils] Proposal: using /etc/os-release in the "platform tag" definition for wheel files

On 11/28/2014 07:03 AM, Nick Coghlan wrote: We've discussed the idea of changing the wheel file naming scheme to deal with Linux previously, but never put together a concrete proposal. The closest we've got is the idea of allowing the platform tag to be customised in pip and perhaps bdist_wheel,

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 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 depend on p

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). ple

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 > reliab

Re: [Distutils] distlib updated - comments sought

On 05.10.2012 19:24, Paul Moore wrote: > On 5 October 2012 17:04, Daniel Holth 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 with setu

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 e

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 bo

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 n

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 Cannon wrote: On Thu, Aug 13, 2009 at 11:23, Jan Matejek wrote: Hello, I'm cross-posting this to distributi...@freedesktop and python-dev, because the topic is relevant to both groups and should be solved in co

Re: [Distutils] PEP 376 - install/uninstall script in Distutils ?

Tarek Ziadé schrieb: > Hello > > I am working on PEP 376 > , and there's > a part about adding an install and uninstall script into Distutils. according to the PEP files mentioned in RECORD are relative paths, which follows the assumption t

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

Kent Tenney schrieb: > On Thu, Apr 9, 2009 at 2:38 PM, Jim Fulton 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

[Distutils] getting installation location from distutils without changing the filesystem?

The current python.m4 macro in automake (aclocal) is a bit broken, because '${prefix}' is passed literally to get_platform_lib(). currently trying to replace this with something different. Besides fixing the quoting, the implmentation seems to be questionable (currently distutils.sysconfig.get_pla

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 >

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 Suck

Re: [Distutils] Annoucing distribute project

Sebastien Douche writes: > On Wed, Sep 24, 2008 at 13:49, Matthias Klose <[EMAIL PROTECTED]> wrote: > > announcing a fork without any objective? what is this fork about? > > Python community *must* have a robust, stable and well featured > infrastructure like Cpan

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 f

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

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 http:/

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 misu

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

[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 'ins

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

Phillip J. Eby writes: > I read the entire policy you linked to, and I don't actually see many > problems. > > It seems to me that the single largest problem in that policy is that it > clearly predates the existence of the distutils. It has no conception of a > Python *project* or *distributi

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 specifi

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

Phillip J. Eby writes: > >what about installing the .egg-info directory without version > >information when --single-version-externally-managed is used? > > Note that the .pyc files will be built for a specific Python version; > that's why the version number is there. yes, but this shouldn't be