I tried getting a list of Trove Classifiers by running ``setup.py register
--list-classifiers`` command, the HTML of https://upload.pypi.org/legacy/
was displayed on the console.
Does this mean that the ``--list-classifiers`` option was broken when the
PyPI endpoint changed? Or was it made intentional change?
Either way, I could not find such a report or announcement.
I confirmed the execution of ``setup.py register --list-classifiers`` with
the following combinations.
Python-3.5 + distutils setup: OK
Python-3.5 + setuptools-26 setup: OK
Python-3.5 + setuptools-27 setup: NG
Python-3.5 + setuptools-38 setup: NG
Python-3.6 + distutils setup: NG
Python-3.6 + setuptools-26 setup: NG
Python-3.6 + setuptools-27 setup: NG
Python-3.6 + setuptools-38 setup: NG
Also, in any of the above combinations, it was OK if I specified
https://pypi.python.org/pypi as the repository.
(BTW, although document says "The --repository or -r option lets you
specify a PyPI server different from the default", if there is no URL
specified in ``.pypirc`` it will display "ValueError: <URL> not found in
So, in my understanding, ``register --list-classifiers`` does not work as
Is there any interest in support for Perforce in pip? Perforce is a
commercial version control system used in mostly corporate environments.
It's also used for FreeBSD development. I have a pull request against the
pypa/pip project (#4857) that allows the following:
pip install p4+p4://host/depot/path
... but as the pip developers lack experience with Perforce, I've been
directed to this mailing list to gauge whether this is a feature worth
adding. I'm aware that Perforce is used in the game and film industries,
but beyond a github issue requesting support (#2754) I'm not sure who else
might use this! I'd appreciate any feedback. Thanks.
To whom it may concern:
My name is Brian Sujecki and I am currently reading Begin to Code With
Python and am unable to import the library snaps even after downloading the
library from the command shell on my mac. It's as if shell hasn't updated
the library. Can you help me? it's driving me crazy I can't move on.
In https://github.com/python/peps/issues/560, a user pointed out that
the current definition of python_version in PEP 508 assumes
single-digit major and minor version numbers:
There's a reasonable chance we'll see 3.10 rather than 4.0 in a few
years time, at which point that definition would break.
The suggested fix is to amend that definition to be:
This seems like a good suggestion to me, so my inclination is to
handle this in a similar way to
fix it in place, and add a section at the end of the PEP listing the
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
Forwarding from pypa-dev
-------- Forwarded Message --------
Subject: Warehouse update: role management & welcoming first-time
Date: Tue, 23 Jan 2018 22:33:46 -0500
From: Sumana Harihareswara <sh(a)changeset.nyc>
In the past week, the Warehouse team's continued making progress
despite a few of us getting sick.
The biggest news is that the master branch now includes the foundation
for a bunch of useful UI for maintainers. Several people collaborated
on a role management feature so a project Owner can add and remove
Maintainer and Owner roles for their projects. This enables us to work
on further release management features.
We made progress on more improvements, including to developer
experience, that you'll see in future updates. And thanks to Srinivas
Garlapati for starting a password reset feature PR that we were able
to finish up and merge.
We've turned a number of umbrella issues into more specific issues for
the maintainer MVP milestone which we continue working on. And if
you're looking for a good first issue as you start contributing to
Warehouse, there's one in our current milestone we'd love help with:
"Valid `Author-email` and `Maintainer-email` fields are rejected".
If you are or know someone who wants to be a first-time contributor,
check out Ernest's offer of neat stickers and mentorship time!
As we get closer to the maintainer MVP milestone, we're preparing to
publicize it and future milestones, including to developers who don't
usually watch distribution and packaging discussions. So we're making
lists of places to post notices, and we're using PyPI data and
libraries.io to find projects and maintainers to personally
contact. And we're working on future announcement channels, e.g.,
banners and a special announcement mailing list.
Once again, thanks to Mozilla for their support for this project.
More next week!
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 up other changes for a future metadata revision.
One change I would like to the current text is to make more explicit that the format of several fields allowing version specifiers (Requires-Dist, Provides-Dist, Obsoletes-Dist, Requires-External) has changed, as PEP 508 removes the need for parentheses around the version specifier.
The section on version specifiers currently refers to PEP 440, which doesn't mention the parentheses at all, and says they are otherwise unchanged from PEP 345, which says parentheses are required. I would like to add some text to that section, such as:
"Following PEP 508, version specifiers no longer need to be surrounded by parentheses in the fields Requires-Dist, Provides-Dist, Obsoletes-Dist or Requires-External, so e.g. `requests >= 2.8.1` is now a valid value. The recommended format is without parentheses, but tools parsing metadata should also be able to handle version specifiers in parentheses."
On 16 January 2018 at 10:03, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
> On 16 January 2018 at 19:47, Paul Moore <p.f.moore(a)gmail.com> wrote:
>> I think that if the pipenv docs had some better guidance on what use
>> cases it was intended to cover (and what it wasn't, in relation to the
>> broader range of pip+virtualenv use cases) that would help people
>> better understand its place in the ecosystem.
> That's fair, and making the PyPUG tutorial specifically about
> *application* dependency management was an initial step in that
> direction - for the library development use case, you're generally
> going to step out of pipenv's world as soon as you try to run your
> tests across multiple versions.
> The basic usage constraint is that pipenv expects you to control your
> target Python version, and it expects you to have exactly one - to go
> beyond that (as is needed for multi-version library support), you'll
> still need to drop down to the lower level tooling, either skipping
> the use of pipenv entirely, or else by using `pipfile lock
> --requirements` to shift levels.
New subject as I don't want to hijack the original thread to rehash my
old issue, but I do want to make a couple of points on this (and I
agree, it's hard to find a good forum to discuss things like this as
1. "pipenv expects you to control your target Python version" - I'm
not 100% sure what that means, but if it's saying "pipenv is only
really for code that will only be used with a single Python version"
then that's basically excluding a huge chunk of Python development.
Specifically, library development of all forms. Admittedly my
experience of what's "typical" is biased strongly by the communities I
work with, but conversely the "writing standalone apps in Python"
community doesn't really seem to have a web presence that we can
promote pipenv through, so it's becoming visible via the "general
Python development" community, which quite biased to libraries, and so
is not the right target audience, from what you say.
2. My specific issues weren't outside that constraint - I *was*
writing code that would only ever need to run under Python 3.6. My
problem was the need for "local" build dependencies, which seems
entirely within that use case. In fairness, the pipenv devs weren't
totally against the functionality I needed, it's just not something
they had considered important. Maybe the problem here is that there
isn't a good set of "developing apps in Python" best practices (as
opposed to the library development situation - use install_requires,
test with tox, ...), so I didn't know the "recommended" solution to my
problem, that pipenv would have been expecting me to use. Maybe it's a
chicken-and-egg situation - the "best practice" is to use pipenv, but
until pipenv gets to encounter all the various use cases, that "best
practice" doesn't properly cover every situation...
As folks are likely aware, legacy PyPI currently supports logging in using OpenID and Google Auth while Warehouse does not. After much deliberation, I’ve decided that Warehouse will not be implementing OpenID or Google logins, and once we shutdown legacy PyPI, OpenID/ and Google logins to PyPI will no longer be possible.
This decision was made for a few reasons:
* Very few people actually are using OpenID or Google logins as it is. In one month we had ~15k logins using the web form, ~5k using basic auth, and 62 using Google and 7 using OpenID. This is a several orders of magnitude difference.
* Regardless of how you log into PyPI (Password or Google/OpenID) you’re required to have a password added to your account to actually upload anything to PyPI. This negates much of the benefit of a federated authentication for PyPI as it stands.
* Keeping these requires ongoing maintenance to deal with any changes in the specification or to update as Google deprecates/changes things.
* Adding support for them to Warehouse requires additional work that could better be used elsewhere, where it would have a higher impact.
I've sent a question to pypa-dev
https://groups.google.com/forum/#!topic/pypa-dev/U6NO55bExbE which can
be summarized: what should we fix or set up to make it easier for you to
hack on Warehouse, especially with a goal of a Warehouse/packaging
sprint at PyCon in May?
I'd appreciate discussion on pypa-dev to keep it in one place (that list
tends to get ~15 posts/month), but if you aren't subscribed there and
don't want to be, go ahead & reply here. :)