Re: [Distutils] What is the official position on distutils?

[Anna Ravenscroft]

+1

On Sun, Sep 4, 2016 at 7:02 AM, Steve Dower  wrote:

> "add it to setuptools first, and then add things to distutils where we
> feel they're sufficiently stable to not need the benefit of the faster
> setuptools update cycle"
>
> I nominate this as the official policy on API changes for distutils, with
> regular maintenance mode policies applying to anything else.
>
> Top-posted from my Windows Phone
> --
> From: Nick Coghlan 
> Sent: ‎9/‎4/‎2016 2:19
> To: Sylvain Corlay 
> Cc: distutils sig 
> Subject: Re: [Distutils] What is the official position on distutils?
>
> On 4 September 2016 at 06:44, Sylvain Corlay 
> wrote:
> > Hi Brett,
> >
> > On Sat, Sep 3, 2016 at 8:05 PM, Brett Cannon  wrote:
> >>
> >>
> >> If Jason is up for the responsibility that seems like a reasonable
> >> approach to take. It also helps test out features in setuptools first
> before
> >> upstreaming it.
> >>
> >
> > How do you see `has_flag` get into setuptools? By monkey-patching
> distutils'
> > ccompiler to have it aside of `has_function` when setuptools is imported?
> >
> > I find really weird the idea of adding this in a convoluted fashion
> instead
> > of allowing incremental improvement of distutils.
>
> The change to distutils would still be a plain patch to distutils, it
> would just be accepted at the API design level in setuptools first.
>
> The problem you're running into right now isn't a technical one - it's
> that there isn't anyone that currently feels like they have sufficient
> design authority over the distutils API to accept your proposal, hence
> Brett starting this thread to address that underlying recurring
> question, rather than the specifics of your change.
>
> Jason *definitely* has that design authority over setuptools though,
> and will be tasked with making any API additions available on older
> versions of Python via setuptools regardless of what policy we adopt
> for distutils maintenance, so if he's amenable to the idea, it makes
> sense to me to invert the order we ask those questions: add it to
> setuptools first, and then add things to distutils where we feel
> they're sufficiently stable to not need the benefit of the faster
> setuptools update cycle.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>


-- 
cordially,
Anna
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PEP 527 - Removing Un(der)used file types/extensions on PyPI

[Anna Ravenscroft]

On Wed, Aug 24, 2016 at 12:06 AM, Nick Coghlan  wrote:

> On 24 August 2016 at 02:46, Donald Stufft  wrote:
> > Abstract
> > 
> >
> > This PEP recommends deprecating, and ultimately removing, support for
> uploading
> > certain unused or under used file types and extensions to PyPI. In
> particular
> > it recommends disallowing further uploads of any files of the types
> > ``bdist_dumb``, ``bdist_rpm``, ``bdist_dmg``, ``bdist_msi``, and
> > ``bdist_wininst``, leaving PyPI to only accept new uploads of the
> ``sdist``,
> > ``bdist_wheel``, and ``bdist_egg`` file types.
>
> +1 on this part. To address MAL's concerns, you may want to state
> explicitly that this proposal is based around a notion of Python
> package publication as a multi-level distribution network where:
>
> * PyPI itself only supports publication in venv-compatible
> Python-specific formats (sdist, wheel, egg)
> * PyPA (the development community) actively encourages
> community-driven and commercial conversions to downstream formats for
> particular target environments:
>
> - the conda cross-platform data analysis ecosystem (conda-forge)
> - the deb based Linux ecosystem (Debian, Ubuntu, etc)
> - the RPM based Linux ecosystem (Fedora, openSuSE, Mageia, etc)
> - the homebrew, MacPorts and fink ecosystems for Mac OS X
> - the Windows Package Management ecosystem (NuGet, Chocalatey, etc)
> - 3rd party creation of Windows MSIs and installers (e.g. Christoph
> Gohlke's work at http://www.lfd.uci.edu/~gohlke/pythonlibs/ )
> - other commercial redistribution formats (ActiveState's PyPM,
> Enthought Canopy, etc)
> - other open source community redistribution formats (Nix, Gentoo,
> Arch, *BSD, etc)
>

+1


>
> This division of responsibility means that we (PyPA) don't need to be
> experts in every platform management system out there, and neither do
> folks wanting to publish software through PyPI.



It also improves the situation for folks trying to document the situation
(like book authors...) by making things much clearer.


> However, we also
> remain open to enhancement proposals for the standard upstream formats
> that allow for easier automation of the conversions to downstream
> formats.
>
> > In addition, this PEP proposes removing support for new uploads of
> sdists using
> > the ``.tar``, ``.tar.bz2``, ``.tar.xz``, ``.zip``, ``.tar.Z``, ``.tgz``,
> > ``.tbz``, and any other extension besides ``.tar.gz``.
>
> I think in this case, campaigning to remove ".zip" support will prove
> to be a false economy, as anything you'd gain from simplifying the
> toolchain implementation you'll lose arguing with folks that would
> prefer for .zip to be the default instead of .tar.gz.
>

+1

-- 
cordially,
Anna
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Python package inquiry

[Anna Ravenscroft]

Hi Meradj,

Are you in the Python interpreter when you type that? If so, that's your
problem. You need to be at your normal command prompt. Open a new shell or
terminal and type that command first.

If you've already started Python and are in the interpreter, that would
indeed, give you a syntax error.

On Tue, Aug 9, 2016 at 7:56 AM, Meradj Aghdam 
wrote:

> To whom it may concern,
>
> Hi,
>
> I am new to Python and I am struggling to install Python packages. I have
> followed the instructions however it does not seem to be working. I am
> trying to install the package through the Python(Command Line), the package
> is economics, and when I put
>
> python -m pip install Economics
>
> It does not work and the error that it is a syntax error. I am using
> Python 2.7. Would you mind kindly let me know how I can install packages?
>
> Your help if very much appreciated,
>
> Kind regards,
>
> Meradj
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>


-- 
cordially,
Anna
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] test.pypi.org is now active

[Anna Ravenscroft]

Great. Just making sure. Updating the chapter now.

On Mon, Aug 1, 2016 at 3:41 PM, Donald Stufft <don...@stufft.io> wrote:

> Yea, instead of testpypi.python.org you’d use test.pypi.org. Specifically
> for uploading you’d use something like:
>
>
> [testpypiorg]
> repository:https://test.pypi.org/legacy/
> username: 
> password: 
>
> For downloading it’d be something like test.pypi.org/simple/
>
>
> On Aug 1, 2016, at 6:39 PM, Anna Ravenscroft <annara...@gmail.com> wrote:
>
> So for testing, we direct testpypi (in the pypirc) to test.pypi.org,
> right?
>
> On Mon, Aug 1, 2016 at 3:26 PM, Donald Stufft <don...@stufft.io> wrote:
>
>> Just an FYI, test.pypi.org is now active (this is the Warehouse instance
>> backed by Test PyPI). Once https://github.com/pypa/warehouse/pull/1416
>> is deployed and merged test.pypi.io will start to redirect to
>> test.pypi.org.
>>
>> No changes to pypi.io have occurred yet, we’re still waiting on the EV
>> Certificate to be deployed for that.
>>
>> —
>> Donald Stufft
>>
>>
>>
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
>
> --
> cordially,
> Anna
>
>
>
> —
> Donald Stufft
>
>
>
>


-- 
cordially,
Anna
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] test.pypi.org is now active

[Anna Ravenscroft]

To be specific, update .pypirc like this:

[testpypi]
repository=https://test.pypi.org/


On Mon, Aug 1, 2016 at 3:39 PM, Anna Ravenscroft <annara...@gmail.com>
wrote:

> So for testing, we direct testpypi (in the pypirc) to test.pypi.org,
> right?
>
> On Mon, Aug 1, 2016 at 3:26 PM, Donald Stufft <don...@stufft.io> wrote:
>
>> Just an FYI, test.pypi.org is now active (this is the Warehouse instance
>> backed by Test PyPI). Once https://github.com/pypa/warehouse/pull/1416
>> is deployed and merged test.pypi.io will start to redirect to
>> test.pypi.org.
>>
>> No changes to pypi.io have occurred yet, we’re still waiting on the EV
>> Certificate to be deployed for that.
>>
>> —
>> Donald Stufft
>>
>>
>>
>> ___
>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
>
>
>
> --
> cordially,
> Anna
>



-- 
cordially,
Anna
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] test.pypi.org is now active

[Anna Ravenscroft]

So for testing, we direct testpypi (in the pypirc) to test.pypi.org, right?

On Mon, Aug 1, 2016 at 3:26 PM, Donald Stufft  wrote:

> Just an FYI, test.pypi.org is now active (this is the Warehouse instance
> backed by Test PyPI). Once https://github.com/pypa/warehouse/pull/1416 is
> deployed and merged test.pypi.io will start to redirect to test.pypi.org.
>
> No changes to pypi.io have occurred yet, we’re still waiting on the EV
> Certificate to be deployed for that.
>
> —
> Donald Stufft
>
>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
cordially,
Anna
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Switch to upload.pypi.org instead of upload.pypi.io

[Anna Ravenscroft]

Great timing! Thanks for letting us know. (I've updated it in the upcoming
Nutshell.)

On Sat, Jul 30, 2016 at 8:17 PM, Donald Stufft  wrote:

> Hey!
>
> The PSF was finally successful in purchasing pypi.org from the person who
> previously owned it. Previously discussions had dropped off and we assumed
> we weren’t going to be able to purchase it, so we moved forward with
> pypi.io instead. However, the person recently came back around and was
> willing to sell it this time for a reasonable price.
>
> We don’t have all of the pypi.io domains switched over to supporting or
> preferring pypi.org yet, but I just enabled upload.pypi.org. If you’re
> currently uploading to Warehouse using upload.pypi.io, nothing will
> break, but I suggest switching your URL to upload.pypi.org instead as it
> may not continue to work forever.
>
> Thanks!
>
> —
> Donald Stufft
>
>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>



-- 
cordially,
Anna
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Request for comment: Proposal to change behaviour of pip install

[Anna Ravenscroft]

I find the whole discussion quite unnerving honestly.

pip install should do just that. notifying me if I have a version and an
upgrade is availalbe for *pip*, makes sense. doing anything *else* is
scary.

I expect --upgrade for upgrading things. THEN it should upgrade to the
latest version, unless I use a flag to specify otherwise.

Note -I'm talking from the "naive user" viewpoint.

On Tue, Jun 28, 2016 at 5:03 PM, Ralf Gommers 
wrote:

>
>
> On Wed, Jun 29, 2016 at 12:45 AM, Robert Collins <
> robe...@robertcollins.net> wrote:
>
>> On 29 June 2016 at 10:38, Ralf Gommers  wrote:
>> >
>> >
>> > On Wed, Jun 29, 2016 at 12:16 AM, Nick Coghlan 
>> wrote:
>> >>
>> >>
>> >> On 26 Jun 2016 23:37, "Pradyun Gedam"  wrote:
>> >> >
>> >> > Hello List!
>> >> >
>> >> > I feel it’s fine to hold back the other changes for later but the
>> >> > upgrade-strategy change should get shipped out to the world as
>> quickly
>> >> > as
>> >> > possible. Even how the change is exposed the user can also be
>> discussed
>> >> > later.
>> >> >
>> >> > I request the list members to focus on only the change of the default
>> >> > upgrade strategy to be non-eager.
>> >> >
>> >> > Does anyone have any concerns regarding the change of the default
>> >> > upgrade
>> >> > strategy to be non-eager? If not, let’s get just that shipped out as
>> >> > soon as possible.
>> >>
>> >> Pairing that change with an explicit "pip upgrade-all" command would
>> get a
>> >> +1 from me, especially if there was a printed warning when the new
>> upgrade
>> >> strategy skips packages the old one would have updated.
>> >
>> > Please do not mix upgrade with upgrade-all. The latter is blocked by
>> lack of
>> > a SAT solver for a long time, and at the current pace that status may
>> not
>> > change for another couple of years. Also mixing these up is
>> unnecessary, and
>> > it was discussed last year on this list already to move ahead with
>> upgrade:
>> > http://article.gmane.org/gmane.comp.python.distutils.devel/24219
>>
>> I realise the consensus on the ticket is that its blocked, but I don't
>> actually agree.
>>
>> Yes, you can't do it *right* without a full resolver, but you can do
>> an approximation that would be a lot better than nothing (just narrow
>> the specifiers given across all requirements). That is actually
>> reasonable when you're dealing with a presumed-good-set of versions
>> (which install doesn't deal with).
>>
>
> Honestly, not sure how to respond. You may be right, I don't have a
> technical opinion on an approximate upgrade-all now. Don't really want to
> have one either - when N core PyPA devs have been in consensus for a couple
> of years, then when dev N+1 comes along at the very last moment to
> challenge that consensus plus make it blocking for something we agreed was
> unrelated, that just feels frustrating (especially because it's becoming a
> pattern).
>
> Mixing separate discussions/implementations up together does seem to be a
> good way to make the whole thing stall again though, so I'll first try
> repeating "this is unnecessary, please do not mix upgrade and upgrade-all".
> Here's an alternative for the small minority that values the current
> upgrade behavior:
>   1. add a --recursive flag to keep that behavior accessible.
>   2. add the printed warning that Nick suggests above.
> That way we can have better defaults soon (Pradyun's PR seems to be in
> decent shape), and add upgrade-all either when someone implements the full
> resolver or when there's agreement on your approximate version.
>
> Ralf
>
>
>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>


-- 
cordially,
Anna
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Switch PyPA from IRC to Gitter or similar

[Anna Ravenscroft]

On Fri, Jun 10, 2016 at 2:53 PM, Glyph  wrote:

> There might be a useful discussion buried in here about where official
> real-time _development_ discussion should go - but then, any weighty
> decisions should be discussed on the mailing list anyway to ensure that
> people from different time zones can see the discussion and participate in
> it asynchronously.
>

+1 for asynchronous discussion and participation.


-- 
cordially,
Anna
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig