On Fri, 26 Mar 2021, at 23:04, Julian Smith wrote:
> I can't tell from pip-18.1's diagnostics what exactly is going wrong.
>
> Given that my setup.py implements the normal distutils-style argv
> handling, i was expecting things to work, but pip-18.1 appears to fail
> before it even tries to run se
On Thu, 25 Mar 2021, at 19:07, Julian Smith wrote:
> I was a little surprised to find out that one can't use pip to create
> an sdist, but i'm a bit late to this party and it looks like there's
> been plenty of discussion about this in the past.
There is now the (quite new) 'build' tool which can
On Tue, 23 Mar 2021, at 11:13, Julian Smith wrote:
> So as far as i can tell, there are two levels of abstraction at which
> on can implement customised Python packaging (the setuptools.setup()'s
> callbacks or the setup.py command line), but neither one seems to be
> documented or standardised.
T
On Thu, 25 Feb 2021, at 09:56, Robin Becker wrote:
> I looked into the manylinux image with docker and it seems that
> manylinux no longer supports 2.7 can anyone confirm this?
It looks like that's correct:
https://github.com/pypa/manylinux/issues/428
The final comment there notes that:
> Last
ourse.
>
> On 9/21/20 9:50 AM, Thomas Kluyver wrote:
> > If it's not already the case, could someone configure the list so that only
> > subscribers can send messages?
> >
> > If we've already got any obvious anti-spam measures like that in place,
> &
If it's not already the case, could someone configure the list so that only
subscribers can send messages?
If we've already got any obvious anti-spam measures like that in place, then
I'm starting to agree that the signal to noise ratio has fallen too low. Of the
10 latest conversations in the
On Tue, 21 Jul 2020, at 21:50, David Mathog wrote:
> ./lib/python3.6/site-packages/pip/_vendor/appdirs.py:#!/usr/bin/env python
Python packaging tools like pip generally differentiate between *scripts*,
which are installed to be run from the command line, and *modules*, which are
imported from o
Hi Fredrik,
You can do an editable install using whichever development tool you've chosen,
e.g. Poetry. The poetry docs (https://python-poetry.org/docs/basic-usage/) say
it does an editable install by default.
Currently, there isn't a standardised way for 'frontend' tools like pip to ask
for a
On Tue, 23 Jun 2020, at 23:51, David Mathog wrote:
> What I am after is some method of keeping exactly one copy of each
> package-version in the common area (ie, one might find foo-1.2,
> foo-1.7, and foo-2.3 there), while also presenting only the one
> version of each (let's say foo-1.7) to a part
;
> FROM quay.io/pypa/manylinux2010_centos-6-no-vsyscall
>
> We will build this image ourself.
>
> Best,
>
>
> On Wed, Feb 26, 2020 at 10:38 AM Thomas Kluyver wrote:
>> __
>> To be precise, these are not uploaded at all - there's no hidden repository
>> on quay
To be precise, these are not uploaded at all - there's no hidden repository on
quay.io AFAICT, and I'm an owner of the pypa team there.
The CI on the manylinux repo always builds both stages one after the other.
They're split as an implementation detail - if I recall correctly, doing
everything
retty geared to our guesses about how an index
> would work; actually implementing the first version of PyPI wasn't a
> part of Greg's project.
>
> Getting far enough along to build a range of C-based extensions was a
> pretty substantial bootstrapping task in the late &#
Hi all,
The metadata specification shows the keyword field as a space separated list:
https://packaging.python.org/specifications/core-metadata/#keywords
PEP 566 backs that up, saying that the transformation to JSON should split that
field on whitespace:
https://www.python.org/dev/peps/pep-0566/
You probably want to try 'repairing' the wheel with auditwheel to make a
manylinux wheel from it:
https://pypi.org/project/auditwheel/
On Wed, Aug 21, 2019, at 4:18 PM, Matthew Brett wrote:
> Hi,
>
> Yes, here you are trying to upload a generic Linux wheel. PyPI
> refuses, because there's no w
On Tue, Aug 20, 2019, at 3:50 PM, Brian Skinn wrote:
> I wonder if there's an OS dependence here, though -- I'm almost certain I've
> had to use `--only-binary` in the past, to avoid pip on my Windows machines
> trying to download and build sdists, even when wheels were available.
Possibly you w
On Mon, May 27, 2019, at 9:55 AM, Richard Neumann wrote:
> I do not wish to have my private software projects liked to my
> company's email account, but have no means on contacting the publisher
> on PyPI nor uploading an updated version of the package's metadata
> since I am not the owner of the P
On Sun, May 19, 2019, at 11:08 PM, Pradyun Gedam wrote:
> Thanks for reaching out. I suggest you file an issue at
> https://github.com/pypa/warehouse for a PEP 541 request. That'll probably be
> the best place.
It looks like Warehouse issues are the de-facto standard place where people
make the
Hi Emma,
On Sun, May 5, 2019, at 12:49 AM, Emma Tosch wrote:
> I have a project that I would like to post on PyPI that clashes with an
> existing project that I believe may be abandoned
I don't have the answers to your actual questions about who to contact. But
have you seen the rather stringe
I think you've done SHA1 instead of SHA256.
On Thu, Mar 21, 2019, at 5:27 PM, Martin Baker wrote:
> The SHA256 listed for setuptools-40.8.0.zip is
> 6e4eec90337e849ade7103723b9a99631c1f0d19990d6e8412dc42f5ae8b304d
>
> But the actual SHA sum is 3547552b1009283f7ae31fded32ad33ed160e671
>
> Martin
Hi Pedro,
I think I've seen some code that does this before, but I can't find it now.
It's generally regarded as a crazy hack, and I wouldn't recommend anyone use it
except as a joke/demo. Some of the reasons:
1. Downloading and running code from the internet if you mistype an import
statement
On Fri, Mar 1, 2019, at 9:59 AM, Sofia Nunes wrote:
> So, let’s assume I fork a package which is on version 2.1. and change its
> name.
> Would my distribution version be 1.0 or 2.2/3.0? Or none of the options?
From a technical perspective, I don't think it matters: if your fork has a new
name,
I forgot to mention that there is work/discussion about supporting
code signing, in PEPs 458 and 480. But it's a complicated topic, and
code signing is not the silver bullet that some commentators seem to
think it is.
On Fri, Feb 8, 2019, at 12:10 PM, Thomas Kluyver wrote:
> On Thu, Feb
On Thu, Feb 7, 2019, at 11:55 PM, Prateek Mohta wrote:
> I wanted to check if the packages available on Pypi.org are scanned
> for any security vulnerabilities or not, can you please confirm.
As far as I know, they are not.
> My concern is how do you control if someone uploads a malicious code
>
On Tue, Jan 29, 2019, at 2:43 PM, Paul Moore wrote:
> And when they start adding
> version numbers to that (like the OP's package >= 10.0 @
> https://github.com/owner/package.git) I can't even begin to understand
> what they think it might mean.
I presume the idea is that it uses that repository l
On Sun, Jan 27, 2019, at 7:47 PM, Paul Moore wrote:
> What is more difficult is the question of whether the PEP should
> change. As Chris pointed out, the previous discussion ended up saying
> that the build directory should not be on sys.path, but acknowledged
> that mandating that might cause iss
I haven't read those discussions in full (sorry to be lazy, but there's
quite a lot there), but my initial take is that the rule doesn't apply
to running setup.py scripts, where there's a greater need for backward
compatibility. I think the rule about the CWD not being on sys.path only
applies to l
Thanks Nathaniel for the explanation.
On Sat, Dec 1, 2018, at 4:39 AM, Nathaniel Smith wrote:
> So the proposal here is to refactor the spec to match how this
> actually works: the official definition of a manylinux_${glibc
> version}_${arch} wheel would be "I promise this wheel will work on any
>
I'll betray my lack of understanding of how ABIs work:
PEP 571 (manylinux2010) defines a set of libraries besides libc which
compatible wheels can safely link against, such as glib and libXrender.
Most of these are only versioned by the filename suffix (like .so.6),
while glibc and a few presumabl
Have you tried using conda envs? Conda avoids duplication by unpacking all
packages to a shared directory and then hard-linking them into environments.
I'm not saying that should preclude doing something similar for virtualenvs,
but it's probably worth looking at existing solutions before embark
On Sun, Sep 30, 2018, at 2:35 PM, Paul Moore wrote:
> Personally, I think that the toolkit approach (standards, interop, low
> level support) is where distutils-sig and PyPA works best. Higher
> level unifications ("one tool to rule them all") have historically
> been much less successful.
I suspe
On Tue, Sep 25, 2018, at 9:13 AM, Paul Moore wrote:
> I personally don't see much advantage in the "dump everything in one
> file" philosophy. so from a personal POV I'd prefer setuptools' config
> to remain in setup.cfg, but if they have reasons for wanting to move,
> the PEP allows them that opti
On Fri, Sep 14, 2018, at 4:26 PM, Paul Moore wrote:
> I don't think it's "hard to predict". I *do* think it's badly documented/not
> standardised.
> ...
> Better would be to have a supported library that exposes the logic pip
> uses (or as I said above, the standard-defined logic) to determine
> s
On Tue, Sep 18, 2018, at 10:02 AM, Antoine Pitrou wrote:
> Nathaniel Smith wrote:
> > It's naughty, you shouldn't do it, and the energy you put into making
> > pseudo-manylinux1 wheels could probably be better put into making finishing
> > up the manylinux2010 work – there's not that much to do.
>
On Mon, Sep 10, 2018, at 1:06 PM, Ian Stapleton Cordasco wrote:
> It seems silly that we're not also considering the portions of the
> world with terrible internet when making this decision. Giant sdists
> make their lives orders of magnitude worse for the benefit of maybe
> 20-30 people who tend t
On Mon, Sep 10, 2018, at 12:33 AM, Bert JW Regeer wrote:
> Speaking as a maintainer of various different packages for the Pylons
> project, we include the following in our sdists:>
> - source code for the package
> - tests for the package
> - documentation for the package
>
> and of course the li
On Mon, Aug 20, 2018, at 2:52 PM, Paul Moore wrote:
> The various hooks take directory paths as arguments, and typically
> return a filename (e.g., build_wheel). The returned filename is always
> explicitly noted as being *a unicode string*. However, argumnents
> (metadata_directory in build_wheel/
On Sat, Aug 4, 2018, at 9:34 AM, Paul Moore wrote:
> Whether timestamps are
> preserved by the wheel building process depends on the build system -
> so the question boils down to "does setup.py bdist_wheel preserve
> timestamps?" in the case of the setuptools backend - which is really a
> question
Hi all,
Do we know of any tool that can, given the name of one or more packages, follow
dependency chains and produce a list of packages in the order they need to be
installed, assuming every package needed will be built from source?
Running "pip download --no-binary :all: ipython" gets me a se
On Mon, Jul 16, 2018, at 11:50 AM, Paul Moore wrote:
> On 16 July 2018 at 11:05, Thomas Kluyver wrote:
> > My proposal was 2a ;-). And that's still my inclination, as we've got
> > examples of people using pyproject.toml for unrelated purposes that
> > shouldn&#x
On Mon, Jul 16, 2018, at 11:02 AM, Paul Moore wrote:
> My inclination would be to recommend 2b. I said that before checking
> whether that was your proposal or Nathaniel's ;-), and it's based
> mostly on gut feel and "that's what pip does now and I don't see any
> reason to change it" though.
My p
On Mon, Jul 16, 2018, at 10:22 AM, Paul Moore wrote:
> 2. If [build-system] is missing, they can take one of the following
> two approaches:
>a) Act as if pyproject.toml is missing altogether
>b) Act as if [build-system] is present, with a requires value of
> ["setuptools", "wheel"]
>
> Wh
On Thu, Jul 12, 2018, at 8:19 AM, Robin Becker wrote:
> The previous
> answer says there is a list so I can use that.
I don't think anyone linked to it yet, so:
https://pypi.org/pypi?%3Aaction=list_classifiers
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email
On Wed, Jul 11, 2018, at 7:32 PM, Chris Jerdonek wrote:
> And yet you can see "License: ReportLab BSD Derived" in the left-hand
> column under "Meta," so how did it get there? Did PyPI previously fall
> back to including the "License" classifier value as is (even if
> invalid) if no "license" field
On Wed, Jul 11, 2018, at 5:37 PM, Nathaniel Smith wrote:
> I don't know why you're having this experience of a classifier you
> think used to be supported no longer being supported. You say the
> license field is the same as on previous uploads. But the license
> field isn't the issue here. Is the
To echo Nathaniel, thanks Nick; in the time I've been on this list, I
think you've done an impressive job of moderating discussions, ensuring
we can reach consensuses and move forwards. And thanks Paul for stepping
up to fill this role. :-)
On Sat, Jul 7, 2018, at 4:15 AM, Nathaniel Smith wrote:
>
On Thu, Jun 28, 2018, at 6:27 PM, Brett Cannon wrote:
> The file was originally meant to target building wheels for libraries.
> It just happens that folks have pushed that out to include apps as
> well. So if the purpose of the file expands to include apps as well
> then that changes what the PEP
On Thu, Jun 28, 2018, at 8:25 AM, Paul Moore wrote:
> I can see the practicality argument here. I don't think (correct me if
> I'm wrong!) that anyone particularly anticipated when we were drafting
> PEP 518 that the tools section would be used by anything other than
> build tools - I know I hadn't
On Sun, Jun 24, 2018, at 9:30 AM, Nathaniel Smith wrote:
> (What does 'flit init' do if someone already has a pyproject.toml, by the
> way?)
At present, it prompts you to overwrite it or cancel. I guess that will need to
change at some point as more tools use pyproject.toml.
--
Distutils-SIG mai
On Sun, Jun 24, 2018, at 7:19 AM, Nathaniel Smith wrote:
> What do you think? (Thomas, I'd love your thoughts in particular :-).)
I agree that it looks nicer, but I'm not sure that it's worth the added
complexity: is 'flit' equivalent to 'flit.__build_api__' (i.e. from flit import
__build_api__)
Since the old PyPI was shut down, I have noticed that it takes a few
minutes for new package updates to show up. I assume that the new site
is more heavily cached.
On Wed, Jun 13, 2018, at 4:01 PM, Vinay Sajip via Distutils-SIG wrote:
> I just uploaded python-gnupg 0.4.3 to PyPI using Twine. Searc
On Thu, May 31, 2018, at 4:39 PM, Matthias Klose wrote:
> It's on the path by default in Debian and Ubuntu, only for new users
> (~/.profile).
Thanks, that's good to hear. I realise it's been a couple of years since I set
up a fresh Linux installation. Upgrades are working too well!
--
Distutils
On Fri, May 25, 2018, at 6:58 PM, Wes Turner wrote:
> ~/.local/bin is user-writeable. If ~/.local was on PATH or by default,
> it could potentially preempt/modify the behavior of system libraries
> and binaries; which is a security risk.
I've heard this argument before, and it doesn't stand up, bec
On Fri, May 25, 2018, at 5:11 PM, Victor Stinner wrote:
> As an user, I want to use "sudo pip install" because packages
> installed in /usr (or /usr/local) are accessible without having to
> touch PYTHONPATH: the install directory is part of the default
> sys.path.
This is also true for "pip insta
On Wed, May 9, 2018, at 7:22 PM, Diane Trout wrote:
> Does the warehouse actually read the readme file directly? or does it
> preferentially look at long_description metadata?
I think it only looks at the long_description metadata; as far as I know
README is just another file in the archive.
If you
I like this practice of writing specifications to better document interfaces
that already exist. However, in this case I wonder if it would be better to
spend the time defining a new, simpler API instead? I think we're currently in
a position where most tools could use a new upload API relativel
On Tue, May 8, 2018, at 5:44 PM, Brett Cannon wrote:
> If it is an Emacs thing then I would vote "no" since that's very editor-
> specific and I suspect trying to support every plaintext file format
> is never-ending.
Currently the metadata spec defines the permitted mimetypes. Maybe we
should make
The recommendation is typically: setup.py for libraries,
requirements.txt for applications. But you may also use requirements.txt
for specific tasks associated with a library, like building the docs.
Donald wrote a blog post which better explains what these two
formats do:https://caremad.io/posts/2
Thanks Sumana & the team for all your work, and for these updates!
On Wed, May 2, 2018, at 2:09 AM, Sumana Harihareswara wrote:
> As I announced yesterday[1], here and on the pypi-announce[2] and
> general Python announcement[3] lists, we have shut down
> legacy.pypi.org, on schedule. (See the no
On Mon, Apr 30, 2018, at 7:37 PM, Wes Turner wrote:
> The signature footer from the message from you that ends with "I think
> it's fixed now." appears to collapse in the Gmail interface,> but no longer
> does with the new, helpful footer?
I think the collapsing is a heuristic based on text seen
distributions have it anyway, maybe we should enforce that it's always
there.
Thomas
On Sun, Apr 15, 2018, at 8:57 AM, Nick Coghlan wrote:
> On 15 April 2018 at 17:31, Thomas Kluyver wrote:
> > The core metadata specification
> > (https://packaging.python.org/specifica
The core metadata specification
(https://packaging.python.org/specifications/core-metadata/ ) notes whether
each field is optional. However there are some discrepancies with my
understanding:
- Download-URL is not marked as optional, but in practice it's obsolete (since
PEP 470) and not very h
Thanks and congratulations to everyone who has worked on pip!
On Sat, Apr 14, 2018, at 1:47 PM, Paul Moore wrote:
> On behalf of the PyPA, I am pleased to announce that pip 10.0 has just
> been released. This release has been the culmination of many months of
> work by the community.
>
> To insta
If I recall correctly, 'pip install --target' works by installing into a
temporary directory, then copying only the library part to the target
directory. So it will throw away any docs/examples/scripts that would be
installed outside the importable package.
On Tue, Apr 10, 2018, at 10:08 PM, Micha
On Thu, Apr 5, 2018, at 2:11 AM, Eric Gorr wrote:
> (c) use https://warehouse.pypa.io/api-reference/json to look for
> distributed wheels for the target OS and python version and
> download them directly. (This may make for a nice flag to add to
> pip somewhere...the ability to specify
A soon-to-be released version of flit will should make use of this
automatically if your description file has a .md extension.
On Wed, Apr 4, 2018, at 6:26 PM, Jon Wayne Parrott via Distutils-SIG wrote:> Hi
distutils-sig,
> If you haven't yet heard, as of April 1st PyPI (warehouse) supports
> Git
On Fri, Mar 23, 2018, at 6:56 AM, alex.gronh...@nextday.fi wrote:
> If someone wanted to make a malicious file, what's preventing them
> from modifying the RECORD to match the modified file when there is no
> cryptographic signing involved?
Right: you need a way to verify RECORD on top of that. Lik
On Thu, Mar 22, 2018, at 9:25 PM, alex.gronh...@nextday.fi wrote:
> I've been wondering about something – zip files already contain CRC
> based checksums for each the stored file. What benefit is there in
> storing a RECORD file which basically duplicates this functionality?
In terms of providing a
On Mon, Mar 19, 2018, at 12:37 PM, Thomas Kluyver wrote:
> If we're happy with that, I can also look at changing the glibc
> version thing, but that will probably involve a bit more actual
> thought. ;-)
I've opened another PR for this:
https://github.com/p
On Wed, Mar 14, 2018, at 2:12 PM, Nick Coghlan wrote:
> Mark was OK with changing PEP 571 over to manylinux2010, but there are
> also some fixes needed for the current Platform Detection section,
> which isn't spelling out the version of glibc used as the baseline
> marker:
> https://mail.python.or
On Mon, Mar 12, 2018, at 2:35 PM, Alex Grönholm wrote:
> The manylinux1 platform only supports x86-64 and x86-32 (i686)
> architectures. A quote from PEP 513:> Because CentOS 5 is only available for
> x86_64 and i686 architectures,
> these are the only architectures currently supported by the
> ma
I'd like to once again prod this PEP towards completion:
https://www.python.org/dev/peps/pep-0566/
The version numbering question has been decided in favour of calling it 2.1.
The remaining question I'm aware of is whether to make the body text (in the
email format of the metadata file) officia
On Mon, Feb 5, 2018, at 2:38 PM, Ivan Pozdeev via Distutils-SIG wrote:
> The point is, a year has negative informativity in this case.
>
> The very reasoning "compatible with most distributions released since
> year " is flawed 'cuz it's vague and nonintuitive. Which is "most"
> distributions? W
on.>> Shouldn't this be changed into 1.3 (along with ditching
>> metadata.json)?>>
>>
>> Thomas Kluyver kirjoitti 12.01.2018 klo 17:26:
>> > On Wed, Jan 10, 2018, at 11:42 PM, Nick Coghlan wrote:
>> >> On 11 January 2018 at 00:5
On Sat, Jan 13, 2018, at 6:39 PM, Matthias Bussonnier wrote:
> Not opposing to open-id/Google-ID removal, but I would love to login-with-
> google, though because I already have an account (and can't associate
> my google account with the PyPI one) I'm not using login with google.
> Also it did not
On Wed, Jan 10, 2018, at 11:42 PM, Nick Coghlan wrote:
> On 11 January 2018 at 00:54, Daniel Holth wrote:
> > AFAICT the only missing feature from old-Metadata-2.0 is "description as
> > message body", which places readable description text after the key/value
> > pairs.
>
> Do pip/PyPI/et al cur
I hope everyone has had a good break. :-)
I'd like to see PEP 566 move forwards. From the last thread, I think people
were mostly happy with it as stands, but there were some proposals to introduce
further metadata changes. I'd suggest that we finalise the PEP as it currently
stands, and save u
On Tue, Dec 19, 2017, at 9:10 PM, Matthias Bussonnier wrote:
> One case I could see is the use of the requires_python metadata. It
> was not included in the recent release of Django 2.0 (which is py 3
> only) and making a new release will be useless as pip on py2 will
> still see Django 2.0.0 as Py
Dustin asked me to bring this issue to this thread:
Metadata version 1.2 (PEP 345) says that version specifiers within a
Requires-Dist field should go in parentheses: "zope.interface (>3.5.0)".
The metadata spec on PyPUG repeats this.
However, PEP 508 says that the parentheses are not needed, and
To pick up the caching discussion again, I've started to experiment with
a couple of different caching techniques.
The headline results: a cold-start scan of entry points goes from about
4.5 seconds with no caching, to 0.45 seconds with caching. There's only
a small difference (for me) between hav
We have now done this, and you can see the new repo here:
https://github.com/pypa/pep517
On Thu, Nov 16, 2017, at 01:31 PM, Paul Moore wrote:
> I'm happy to (not sure what needs to be done, but I'm sure I can
> muddle it through ;-))
> Paul
>
> On 16 November 2017
On Thu, Nov 16, 2017, at 12:46 PM, Nick Coghlan wrote:
> On 16 November 2017 at 21:22, Thomas Kluyver
> wrote:>> On Sun, Nov 12, 2017, at 10:51 PM, Nick
> Coghlan wrote:
>> > +1 from me, too.
>>
>> Whose further agreement should we get for this? And - if t
On Sun, Nov 12, 2017, at 10:51 PM, Nick Coghlan wrote:
> +1 from me, too.
Whose further agreement should we get for this? And - if there is
agreement - how do we do the transfer? If someone briefly gives me
permission to create repos in the PyPA org, I can use Github's transfer
feature. Otherwise,
On Sun, Nov 12, 2017, at 07:21 PM, Paul Moore wrote:
> Is it (in your opinion) something that pip might be able to use? The
> biggest potential hurdle, I would imagine, is that if pep517.envbuild
> uses pip to install dependencies, and pip uses pep517.envbuild,
> there's a risk of a recursive loop
I have found a bit more time to work on my PEP 517 consumer API:
https://github.com/takluyver/pep517
It provides two main interfaces:
- 'pep517.wrappers' is a lower-level interface to call the backend hooks
in a subprocess.
- 'pep517.envbuild' is a higher-level interface which creates a
temporary
On Tue, Oct 31, 2017, at 12:49 PM, Jeremy Stanley wrote:
> Do the two share enough common code for successful uploading to a
> devpi instance to be indicative of whether PyPI will accept or
> reject on the grounds of, e.g., invalid trove classifiers (this one
> in particular has been the most commo
On Mon, Oct 30, 2017, at 07:16 PM, RonnyPfannschmidt wrote:
> in order to elevate those issues i would like to propose a new
> installation layout,
> where instead of storing each distribution in every python all
> distributions would share a storage, and each individual environment
> would only ha
On Thu, Oct 26, 2017, at 03:57 PM, Daniel Holth wrote:
> Would something as simple as a file per sys.path with the 'last
> modified by installer' date be helpful? You could check those to
> determine whether your cache was out of date.
I wonder if we could use the directory mtime for this? It's o
On Sat, Oct 21, 2017, at 07:59 AM, Nick Coghlan wrote:
> Yeah, here's the gist of what I had in mind regarding the malware
> problem (i.e. aiming to ensure we don't get all of setup.py's problems
> back again):>
> - a package's own install hooks do *not* get called for that package
> - hooks only
On Fri, Oct 20, 2017, at 07:31 PM, Marius Gedminas wrote:
> Please do not forget about gui_scripts entry points!
I haven't forgotten about them in the draft spec:
https://github.com/pypa/python-packaging-user-guide/pull/390/files#diff-089b079de062f6fdb759bb719b79e6c8R121
__
On Fri, Oct 20, 2017, at 07:24 PM, Doug Hellmann wrote:
> I have been trying to find time to do something like that within
> stevedore for a while to solve some client-side startup performance
> issues with the OpenStack client. I would be happy to help add it
> to entrypoints instead and use it fr
On Fri, Oct 20, 2017, at 01:58 PM, Wes Turner wrote:
> What were the issues with setuptools entry points here (in 2014, when
> you two were opposed to adding them to sendibly list ipython
> extensions)?
I'm impressed by your memory! The main issue then was that it implied
that extension authors wou
On Fri, Oct 20, 2017, at 01:36 PM, Donald Stufft wrote:
> Entry points have a lot of problems and I know of multiple systems
> that have either moved away from them, had to hack around how bad they
> are, have refused to implement them because of previous pain felt by
> them, are looking for ways t
On Fri, Oct 20, 2017, at 01:18 PM, Donald Stufft wrote:
> I guess we shouldn’t have done PEP 517 or PEP 518 because, by your
> logic here, since it won’t be supported by existing tooling, there
> won’t be any incentive for people to use it ever.
I see this as having a similar purpose to those PEPs:
On Fri, Oct 20, 2017, at 12:50 PM, Donald Stufft wrote:
> * Since it is a packaging standard, then it is expected that all
> packaging tools will be updated to work with it.
Where packaging tools need to know about it, they already have to.
Where they don't, writing a standard doesn't imply that
On Fri, Oct 20, 2017, at 12:15 PM, Donald Stufft wrote:
> Tell you what, I’ll drop everything today and write up a PEP...
Donald, why are you so determined that this spec should not be created?
Your time is enormously valuable, so why would you drop everything to
write a PEP which implies changes
I would also be happy to add a section to the document describing the
specific use of entry points for defining scripts to install.
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
On Fri, Oct 20, 2017, at 05:42 AM, Nick Coghlan wrote:
> I'm wondering if rather than jumping straight to a PEP, it may make
> sense to instead initially pursue this idea as a *non-*standard,
> implementation dependent thing specific to the "entrypoints" project.
> There are a *lot* of challenges t
On Thu, Oct 19, 2017, at 09:04 PM, Donald Stufft wrote:
> Like I said, I’m perfectly fine documenting that if you add an
> entry_points.txt to the .dist-info directory, that is an INI file that
> contains a section named “console_scripts” and define what is valid
> inside of the console_scripts sec
On Thu, Oct 19, 2017, at 08:29 PM, Donald Stufft wrote:
> Because it is? A generic plugin mechanism is not a packaging feature
> any more then a HTTP client is a packaging feature, but setuptools
> contains one of those too. Since setuptools was in large part a
> packaging library, it will of cours
On Thu, Oct 19, 2017, at 08:01 PM, Donald Stufft wrote:
>
>> On Oct 19, 2017, at 2:54 PM, Thomas Kluyver
>> wrote:>>
>> I don't think this needs to be controversial. They are a de-facto
>> packaging standard, whether or not that's theoretically necess
1 - 100 of 268 matches
Mail list logo
