Re: Automation and other changes

On 2 April 2017 at 14:03, Donald Stufft wrote: > I was just about to ask if you thought if a daily or weekly email to > pypa-dev enumerating the contents of our review queue (where review queue == > the list of PRs waiting for action from a core dev) would be useful in a >

Re: Automation and other changes

On 2 April 2017 at 13:14, Donald Stufft wrote: > Another case of this that happens to me is I’ll get an email for the PR, see > it, review it, think it’s a good idea, but the tests are still running (and > they take 30+ minutes to run) so I’ll wait for that and end up forgetting

Re: Automation and other changes

On 2 April 2017 at 13:07, Donald Stufft wrote: > Thoughts? Sounds reasonable - I didn't mean to say that I thought what you were doing was wrong, just that the net effect on me was likely to be minimal because I use a purely email-based workflow. And yes, you're right that does

NEWS entries for pip

One thing I've just noticed with the new NEWS process for pip is that it's made the PR process a 2-step process - you have to first make the change, then once you submit the PR you have a PR number that you can use to add a NEWS entry as a second commit. That's both clumsy from a workflow POV,

Re: GSoC, Pradyun, and Us

On 19 May 2017 at 11:58, Donald Stufft wrote: > I just occurred to me that I don’t think we ever announced it or made it > official here. > > You might have noticed Pradyun making some PRs lately, he’s been accepted as > a GSoC student working on pip. Right now he’s in the

Re: NEWS entries for pip

On 2 May 2017 at 20:50, Donald Stufft wrote: > It’s generally only a two step process if there isn’t an existing issue > you’re fixing. If you’re fixing an issue you can/should just use the issue’s > number instead of the PRs number. We can make it possible to do like > .feature

Re: Remove access from inactive maintainers

On 5 June 2017 at 23:05, Donald Stufft wrote: > Absent any objections, I’ll take these actions in the next couple of days > (and I’ll need PyPI usernames for Paul and Xavier). Fine with me (my PyPI username is pf_moore). Paul

Re: Fixing the bash from activate script, again

On 28 September 2017 at 18:11, Jakub Bocheński wrote: > +1 for what it's worth... > > I think it's really sad to see people go out of their way to help improve > this project and are just ignored. I've already responded in much more detail on the virtualenv-users list,

Re: Fixing the bash from activate script, again

On 28 September 2017 at 21:11, Jakub Bocheński wrote: >> Feel free to do that. I've used up all my open source time for today, >> sorry. > Would love to do that, but the list you are mentioning " virtualenv-users" > doesn't seem to exist. At least google group only finds

Re: Fixing the bash from activate script, again

On 29 September 2017 at 16:51, Sorin Sbarnea wrote: > I already said that I am willing to help with that and I could start by > doing few reviews (no permissions to perform them now). I already suggested contributing improvements to the test suite, so we get to a point where

Re: Fixing the bash from activate script, again

On 28 September 2017 at 23:41, 'Ionel Cristian Mărieș' via pypa-dev wrote: > Just my two cents here. I was a bit angry > too > with virtualenv some way back, up to a point that I've took dstufft's > rewrite branch to a better state (supporting up to 3.4, integration

New pip core developer: Pradyun Gedam

Many of you will have seen the work Pradyun has been doing on the pip tracker recently. He's been doing a fantastic job, and as a result, we've offered him core developer status - and I'm pleased to say that he's accepted :-) Welcome, Pradyun - thanks for all the work you've been doing, and

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

On 21 October 2017 at 12:15, Nick Coghlan wrote: > (Note: this is entirely speculative, and I have no idea how hard it would > be, so please read it as the question it's intended to be) No problem - I don't know myself how hard some of this would be, either ;-) > Do you know

Re: Announcement: Pip 10 is coming, and will move all internal APIs

On 20 October 2017 at 23:53, Richard Jones wrote: > Hiya Paul, > > There's a bunch of tooling out there using pip's internals to extending > pip's functionality. Could you please provide a some reasoning as to why > they're all going to be broken at pip 10, and possibly

Re: Announcement: Pip 10 is coming, and will move all internal APIs

On 20 October 2017 at 21:55, Doug Hellmann wrote: > Excerpts from Paul Moore's message of 2017-10-20 14:22:03 +0100: >> We're in the process of starting to plan for a release of pip (the >> long-awaited pip 10). We're likely still a month or two away from a >> release, but

Re: Thoughts on '--force' option for pip install?

Maybe the check could simply warn rather than abort the install when used with --target? Actually, --target installs are weird in so many ways, that longer term it might be better to split them out as a completely separate option. But that's probably more than we want to tackle for this question.

Announcement: Pip 10 is coming, and will move all internal APIs

We're in the process of starting to plan for a release of pip (the long-awaited pip 10). We're likely still a month or two away from a release, but now is the time for people to start ensuring that everything works for them. One key change in the new version will be that all of the internal APIs

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

On 20 October 2017 at 14:26, Matthew Brett wrote: > Thanks for the heads-up. > > Will y'all be doing a PyPI pre-release so we can test with `pip > install --pre -U pip`? We've not yet decided on that. Traditionally I don't think we have done so, but I'm inclined to think

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

On 20 October 2017 at 14:55, Jannis Gebauer wrote: > Thanks for the heads-up, Paul. > > I’m currently using `pip.get_installed_distributions` and as far as I can > see that has moved into `_internal`, too: >

Re: release blockers for pip

On 7 March 2018 at 16:28, Sumana Harihareswara wrote: > On 03/07/2018 11:22 AM, Sumana Harihareswara wrote: >> I saw today that pip's last release, 9.0.1, was in November 2016. >> https://pypi.org/project/pip/#history >> >> Since that release, 250+ PRs have been merged: >>

Re: Getting the name of a wheel

On Tue, 5 Mar 2019 at 16:40, wrote: > > Hi all, > > I have a use case where I would like to be able to discover the name that a > wheel will be given without actually building the wheel first. So if I had a > source directory like this: > > src/ > my_package/ > setup.py > > Here my_package

Re: upcoming work to facilitate PyPA communications/roadmaps

You should have it, if I'm reading things right. You're in the "PEP Authors" team, which has write privileges on that repo. On Sun, 28 Jul 2019 at 23:02, Sumana Harihareswara wrote: > > On Thursday, July 18, 2019 at 12:12:01 PM UTC-4, Sumana Harihareswara wrote: >> >> I aim to have Changeset

Re: upcoming work to facilitate PyPA communications/roadmaps

On Mon, 29 Jul 2019 at 14:54, Dustin Ingram wrote: > > Somewhat surprising to me that "PEP Authors" have the ability to commit to > pypa/pypa.io, and that Sumana is on that team (AFAIK, she has not authored a > PEP). Perhaps we need to make a separate team? Agreed it seemed odd to me. Paul --

Re: Determining what to retrieve from pypi and/or devpi-server

On Fri, 22 Nov 2019 at 18:12, Michael Felt wrote: > So, back to real comment - Paul, where can I best answer, deeper, your > comment re: > > "I thought that was something that had been discussed on the Pip > tracker, but maybe the implications weren't clear (I don't really > understand the AIX

Re: Determining what to retrieve from pypi and/or devpi-server

I replied on the bpo issue. On Fri, 22 Nov 2019 at 09:21, Michael Felt wrote: > > Just wanted to thank everyone for their replies and feedback. > > I have a PR for CPython (https://bugs.python.org/issue38021 and > https://github.com/python/cpython/pull/17303) as well as > pypa/packaging -

Re: [GitHub] Third-party application approval request for Python Packaging Authority

I just saw this request. I took a quick look at the Tidelift website, but I'm not clear on what it provides or what implications approving it would have. Can someone clarify what this is (presumably Bernat would be best able to do so)? Paul On Sun, 12 Jan 2020 at 11:18, Python Packaging

Re: [GitHub] Third-party application approval request for Python Packaging Authority

On Sun, 12 Jan 2020 at 15:15, Sviatoslav Sydorenko wrote: > I can answer this question. Tidelift is a startup that tries to solve > the problem of paying FOSS maintainers. > They offer a sort of FOSS subscription to enterprise customers. > Maintainers can register there and get payouts for their

Re: [GitHub] Third-party application approval request for Python Packaging Authority

On Sun, 12 Jan 2020 at 15:48, Sviatoslav Sydorenko wrote: > Yep, except as per limitation above, it affects the org too. Odd that if setuptools is part of Tidelift, that they didn't have to install the app PyPA-wide, then... Never mind, at this point it's just my own curiosity (and I certainly

Re: pip install from local sdist with only package name

You just need to add the --find-links option to pip and specify the directory containing the tarballs. Then pip will include that directory in its search. On Wed, 8 Jan 2020 at 11:52, DH wrote: > > Hello, > > I've written some packages that I want to archive as local sdists. Lets say > they are

Re: archive this group & redirect conversation elsewhere?

I'm happy for this group to be archived. On Sun, 10 May 2020 at 11:45, Sumana Harihareswara wrote: > > Hey all -- I've heard no opposition, onlist or offlist. As I asked in April: > please speak up if I'm wrong, or if there's some other reason to keep this > Google group going. And please