From dustin.ingram at gmail.com  Tue Dec  5 11:39:05 2017
From: dustin.ingram at gmail.com (Dustin Ingram)
Date: Tue, 5 Dec 2017 10:39:05 -0600
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software Packages 1.3
Message-ID: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>

Hi all,

I'd appreciate your feedback on the following Metadata 1.3 PEP.

The goal here is not to provide a full specification for all fields as
in previous PEPs, but to:

* Motivate and describe the addition of the new fields or changes to
existing fields;
* Point to the Core Metadata Specifications reference document as the
canonical source for the specification.

Previous discussions:
* https://mail.python.org/pipermail/distutils-sig/2017-September/031465.html
* https://github.com/python/peps/issues/388

Thanks,
D.


PEP: 566
Title: Metadata for Python Software Packages 1.3
Version: $Revision$
Last-Modified: $Date$
Author: Dustin Ingram <di at di.codes>
Discussions-To: distutils-sig <distutils-sig at python.org>
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 1-Dec-2017
Python-Version: 3.x
Post-History:
Replaces: 345


Abstract
========

This PEP describes the changes between versions 1.2 and 1.3 of the core
metadata specification for Python packages. Version 1.2 is specified in PEP
345.

It also changes to the canonical source for field specifications to the `Core
Metadata Specification`_ reference document, which includes specifics of the
field names, and their semantics and usage.

Fields
======

The canonical source for the names and semantics of each of the supported
metadata fields is the `Core Metadata Specification`_ document.

Fields marked with "(Multiple use)" may be specified multiple times in a single
PKG-INFO file.  Other fields may only occur once in a PKG-INFO file.  Fields
marked with "(optional)" are not required to appear in a valid PKG-INFO file;
all other fields must be present.

New in Version 1.3
------------------

Description-Content-Type (optional)
:::::::::::::::::::::::::::::::::::

A string stating the markup syntax (if any) used in the distribution's
description, so that tools can intelligently render the description.

Historically, tools like PyPI assume that a package's description is formatted
in `reStructuredText (reST)
<http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html>`_, and
fall back on plain text if the description is not valid reST.

The introduction of this field allows PyPI to support additional types of
markup syntax, and not need to make this assumption.

The full specification for this field is defined in the `Core Metadata
Specification`_.


Provides-Extra (optional, multiple use)
:::::::::::::::::::::::::::::::::::::::

A string containing the name of an optional feature. Must be a valid Python
identifier. May be used to make a dependency conditional on whether the
optional feature has been requested.

This introduction of this field allows packge installation tools (such as
``pip``) to determine which extras are provided by a given package, and so that
package publication tools (such as ``twine``) can check for issues with
environment markers which use extras.

The full specification for this field is defined in the `Core Metadata
Specification`_.

Changed in Version 1.3
----------------------

Name
::::

The specification for the format of this field is now identical to the
distribution name specification defined in PEP 508.

Version Specifiers
==================

Version numbering requirements and the semantics for specifying comparisons
between versions are defined in PEP 440.

Environment markers
===================

An **environment marker** is a marker that can be added at the end of a
field after a semi-colon (";"), to add a condition about the execution
environment.

The environment marker format used to declare such a condition is defined in
the environment markers section of PEP 508.

JSON-compatible Metadata
========================

It may be necessary to store metadata in a data structure which does not
allow for multiple repeated keys, such as JSON.

The canonical method to transform metadata fields into such a data structure is
as follows:

#. The original key-value format should be read with
   ``email.parser.HeaderParser``;
#. All transformed keys should be reduced to lower case, but otherwise should
   retain all other characters;
#. The transformed value for any field marked with "(Multiple-use") should be a
   single list containing all the original values for the given key;
#. The ``Keywords`` field should be converted to a list by splitting the
   original value on whitespace characters;
#. The result should be stored as a string-keyed dictionary.

Summary of Differences From PEP 345
===================================

* Metadata-Version is now 1.3.

* Fields are now specified via the `Core Metadata Specification`_.

* Added two new fields: ``Description-Content-Type`` and ``Provides-Extra``

* Acceptable values for the ``Name`` field are now specified as per PEP 508.

* Added canonical method of transformation into JSON-compatible data structure.

References
==========

This document specifies version 1.3 of the metadata format.
Version 1.0 is specified in PEP 241.
Version 1.1 is specified in PEP 314.
Version 1.2 is specified in PEP 345.

.. _`Core Metadata Specification`:
   https://packaging.python.org/specifications/core-metadata/

Copyright
=========

This document has been placed in the public domain.

Acknowledgements
================

Thanks to Nick Colgan for contributing to this PEP.


..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 80
   End:

From tseaver at palladion.com  Tue Dec  5 12:19:34 2017
From: tseaver at palladion.com (Tres Seaver)
Date: Tue, 5 Dec 2017 12:19:34 -0500
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
Message-ID: <p06kid$lft$1@blaine.gmane.org>

On 12/05/2017 11:39 AM, Dustin Ingram wrote:
> Hi all,
> 
> I'd appreciate your feedback on the following Metadata 1.3 PEP.
> 
> The goal here is not to provide a full specification for all fields as
> in previous PEPs, but to:
> 
> * Motivate and describe the addition of the new fields or changes to
> existing fields;
> * Point to the Core Metadata Specifications reference document as the
> canonical source for the specification.
> 
> Previous discussions:
> * https://mail.python.org/pipermail/distutils-sig/2017-September/031465.html
> * https://github.com/python/peps/issues/388

LGTM.


Tres.
-- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com


From p.f.moore at gmail.com  Tue Dec  5 12:52:08 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 5 Dec 2017 17:52:08 +0000
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
Message-ID: <CACac1F_fVv1MMOunAtziWD0uQVfri1VGzDs923yMPa9d0_+sdA@mail.gmail.com>

LGTM.

I was a bit confused at first by the fact that you describe
environment markers but not where they are allowed. On checking, I
find that this is defined in version 1.2 (PEP 345). It might be worth
a small clarification that this (and name and version specifiers) are
still used in the same way as in PEP 345. Better to be explicit than
implicit and all that :-)

Formatting nit - the "Name" section header is at a different level
than the other two. You probably want the other two with "::::"
underlines.

Paul

On 5 December 2017 at 16:39, Dustin Ingram <dustin.ingram at gmail.com> wrote:
> Hi all,
>
> I'd appreciate your feedback on the following Metadata 1.3 PEP.
>
> The goal here is not to provide a full specification for all fields as
> in previous PEPs, but to:
>
> * Motivate and describe the addition of the new fields or changes to
> existing fields;
> * Point to the Core Metadata Specifications reference document as the
> canonical source for the specification.
>
> Previous discussions:
> * https://mail.python.org/pipermail/distutils-sig/2017-September/031465.html
> * https://github.com/python/peps/issues/388
>
> Thanks,
> D.
>
>
> PEP: 566
> Title: Metadata for Python Software Packages 1.3
> Version: $Revision$
> Last-Modified: $Date$
> Author: Dustin Ingram <di at di.codes>
> Discussions-To: distutils-sig <distutils-sig at python.org>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 1-Dec-2017
> Python-Version: 3.x
> Post-History:
> Replaces: 345
>
>
> Abstract
> ========
>
> This PEP describes the changes between versions 1.2 and 1.3 of the core
> metadata specification for Python packages. Version 1.2 is specified in PEP
> 345.
>
> It also changes to the canonical source for field specifications to the `Core
> Metadata Specification`_ reference document, which includes specifics of the
> field names, and their semantics and usage.
>
> Fields
> ======
>
> The canonical source for the names and semantics of each of the supported
> metadata fields is the `Core Metadata Specification`_ document.
>
> Fields marked with "(Multiple use)" may be specified multiple times in a single
> PKG-INFO file.  Other fields may only occur once in a PKG-INFO file.  Fields
> marked with "(optional)" are not required to appear in a valid PKG-INFO file;
> all other fields must be present.
>
> New in Version 1.3
> ------------------
>
> Description-Content-Type (optional)
> :::::::::::::::::::::::::::::::::::
>
> A string stating the markup syntax (if any) used in the distribution's
> description, so that tools can intelligently render the description.
>
> Historically, tools like PyPI assume that a package's description is formatted
> in `reStructuredText (reST)
> <http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html>`_, and
> fall back on plain text if the description is not valid reST.
>
> The introduction of this field allows PyPI to support additional types of
> markup syntax, and not need to make this assumption.
>
> The full specification for this field is defined in the `Core Metadata
> Specification`_.
>
>
> Provides-Extra (optional, multiple use)
> :::::::::::::::::::::::::::::::::::::::
>
> A string containing the name of an optional feature. Must be a valid Python
> identifier. May be used to make a dependency conditional on whether the
> optional feature has been requested.
>
> This introduction of this field allows packge installation tools (such as
> ``pip``) to determine which extras are provided by a given package, and so that
> package publication tools (such as ``twine``) can check for issues with
> environment markers which use extras.
>
> The full specification for this field is defined in the `Core Metadata
> Specification`_.
>
> Changed in Version 1.3
> ----------------------
>
> Name
> ::::
>
> The specification for the format of this field is now identical to the
> distribution name specification defined in PEP 508.
>
> Version Specifiers
> ==================
>
> Version numbering requirements and the semantics for specifying comparisons
> between versions are defined in PEP 440.
>
> Environment markers
> ===================
>
> An **environment marker** is a marker that can be added at the end of a
> field after a semi-colon (";"), to add a condition about the execution
> environment.
>
> The environment marker format used to declare such a condition is defined in
> the environment markers section of PEP 508.
>
> JSON-compatible Metadata
> ========================
>
> It may be necessary to store metadata in a data structure which does not
> allow for multiple repeated keys, such as JSON.
>
> The canonical method to transform metadata fields into such a data structure is
> as follows:
>
> #. The original key-value format should be read with
>    ``email.parser.HeaderParser``;
> #. All transformed keys should be reduced to lower case, but otherwise should
>    retain all other characters;
> #. The transformed value for any field marked with "(Multiple-use") should be a
>    single list containing all the original values for the given key;
> #. The ``Keywords`` field should be converted to a list by splitting the
>    original value on whitespace characters;
> #. The result should be stored as a string-keyed dictionary.
>
> Summary of Differences From PEP 345
> ===================================
>
> * Metadata-Version is now 1.3.
>
> * Fields are now specified via the `Core Metadata Specification`_.
>
> * Added two new fields: ``Description-Content-Type`` and ``Provides-Extra``
>
> * Acceptable values for the ``Name`` field are now specified as per PEP 508.
>
> * Added canonical method of transformation into JSON-compatible data structure.
>
> References
> ==========
>
> This document specifies version 1.3 of the metadata format.
> Version 1.0 is specified in PEP 241.
> Version 1.1 is specified in PEP 314.
> Version 1.2 is specified in PEP 345.
>
> .. _`Core Metadata Specification`:
>    https://packaging.python.org/specifications/core-metadata/
>
> Copyright
> =========
>
> This document has been placed in the public domain.
>
> Acknowledgements
> ================
>
> Thanks to Nick Colgan for contributing to this PEP.
>
>
> ..
>    Local Variables:
>    mode: indented-text
>    indent-tabs-mode: nil
>    sentence-end-double-space: t
>    fill-column: 80
>    End:
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

From di at di.codes  Tue Dec  5 13:11:06 2017
From: di at di.codes (Dustin Ingram)
Date: Tue, 5 Dec 2017 12:11:06 -0600
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CACac1F_fVv1MMOunAtziWD0uQVfri1VGzDs923yMPa9d0_+sdA@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <CACac1F_fVv1MMOunAtziWD0uQVfri1VGzDs923yMPa9d0_+sdA@mail.gmail.com>
Message-ID: <CACHw_mRhssmtE5d+bTawFLFBxj2PTeTRN8nDQWvz6tfW1vAjHA@mail.gmail.com>

> I was a bit confused at first by the fact that you describe
> environment markers but not where they are allowed. On checking, I
> find that this is defined in version 1.2 (PEP 345). It might be worth
> a small clarification that this (and name and version specifiers) are
> still used in the same way as in PEP 345. Better to be explicit than
> implicit and all that :-)

Thanks Paul. I will add a note to to these sections indicating that
their usage is otherwise unchanged from PEP 345.

> Formatting nit - the "Name" section header is at a different level
> than the other two. You probably want the other two with "::::"
> underlines.

Unless I'm misunderstanding your nit, I believe this is already the case?

Thanks again,
D.

From p.f.moore at gmail.com  Tue Dec  5 15:21:26 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 5 Dec 2017 20:21:26 +0000
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CACHw_mRhssmtE5d+bTawFLFBxj2PTeTRN8nDQWvz6tfW1vAjHA@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <CACac1F_fVv1MMOunAtziWD0uQVfri1VGzDs923yMPa9d0_+sdA@mail.gmail.com>
 <CACHw_mRhssmtE5d+bTawFLFBxj2PTeTRN8nDQWvz6tfW1vAjHA@mail.gmail.com>
Message-ID: <CACac1F_fepqGnRrGnYga+qBL4X=6gvpQsJKVpHF3hV3qpnHYuQ@mail.gmail.com>

On 5 December 2017 at 18:11, Dustin Ingram <di at di.codes> wrote:
>> I was a bit confused at first by the fact that you describe
>> environment markers but not where they are allowed. On checking, I
>> find that this is defined in version 1.2 (PEP 345). It might be worth
>> a small clarification that this (and name and version specifiers) are
>> still used in the same way as in PEP 345. Better to be explicit than
>> implicit and all that :-)
>
> Thanks Paul. I will add a note to to these sections indicating that
> their usage is otherwise unchanged from PEP 345.
>
>> Formatting nit - the "Name" section header is at a different level
>> than the other two. You probably want the other two with "::::"
>> underlines.
>
> Unless I'm misunderstanding your nit, I believe this is already the case?

Sorry, I was rushing and didn't take the time to fight with Gmail to
do inline comments. What I was trying to get at:

> Changed in Version 1.3
> ----------------------
>
> Name
> ::::
>
> The specification for the format of this field is now identical to the
> distribution name specification defined in PEP 508.
>
> Version Specifiers
> ==================

This should be

  ::::::::::::::::::

so "Version Specifiers" is at the same level as "Name"

>
> Version numbering requirements and the semantics for specifying comparisons
> between versions are defined in PEP 440.
>
> Environment markers
> ===================

Same here, should be

  :::::::::::::::::::

> An **environment marker** is a marker that can be added at the end of a
> field after a semi-colon (";"), to add a condition about the execution
> environment.
>
> The environment marker format used to declare such a condition is defined in
> the environment markers section of PEP 508.

Paul

From di at di.codes  Tue Dec  5 15:34:47 2017
From: di at di.codes (Dustin Ingram)
Date: Tue, 5 Dec 2017 14:34:47 -0600
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CACac1F_fepqGnRrGnYga+qBL4X=6gvpQsJKVpHF3hV3qpnHYuQ@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <CACac1F_fVv1MMOunAtziWD0uQVfri1VGzDs923yMPa9d0_+sdA@mail.gmail.com>
 <CACHw_mRhssmtE5d+bTawFLFBxj2PTeTRN8nDQWvz6tfW1vAjHA@mail.gmail.com>
 <CACac1F_fepqGnRrGnYga+qBL4X=6gvpQsJKVpHF3hV3qpnHYuQ@mail.gmail.com>
Message-ID: <CACHw_mQOZox_4eEO8B6zBXtvk6YrUdUtBOW0ZN=GF5pg-0M7gw@mail.gmail.com>

Ah, I see, by "other two" I thought you meant the other two new fields.

Looking at https://www.python.org/dev/peps/pep-0566/ might make it
more clear that I originally intended the "New in Version 1.3" and
"Changed in Version 1.3" headings to only be under the "Fields"
heading, so the outline would be:

* Abstract
* Fields
  - New in Version 1.3
    * Description-Content-Type (optional)
    * Provides-Extra (optional, multiple use)
  - Changed in Version 1.3
    * Name
* Version Specifiers
* Environment markers
* JSON-compatible Metadata
* Summary of Differences From PEP 345
* References
* Copyright
* Acknowledgements

However I could see the value in inverting this a bit to be:

* Abstract
* New in Version 1.3
  - Fields
    * Description-Content-Type (optional)
    * Provides-Extra (optional, multiple use)
* Changed in Version 1.3
  - Fields
    * Name
  - Version Specifiers
  - Environment markers
  - JSON-compatible Metadata
* Summary of Differences From PEP 345
* References
* Copyright
* Acknowledgements

If this is preferable.

Thanks,
D.

From njs at pobox.com  Tue Dec  5 16:02:56 2017
From: njs at pobox.com (Nathaniel Smith)
Date: Tue, 5 Dec 2017 13:02:56 -0800
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CAPJVwB=z=o_kpEy6xT+bdRTzekVSruM-myCYP5Ud2p84pan3Xw@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <CAPJVwB=zewKY5vZVP5d44c6eK_rtp86sp1S59NFZf2B1ebiiPg@mail.gmail.com>
 <CAPJVwBnZ6VKkEVqpOXPLjWPmBALWV-vk-6660gi7-S6tKjQ8sA@mail.gmail.com>
 <CAPJVwB=xFiJBhQi0AQRsag737FK62a93-ROEg8+gSzvOA0y4Yw@mail.gmail.com>
 <CAPJVwB=z=o_kpEy6xT+bdRTzekVSruM-myCYP5Ud2p84pan3Xw@mail.gmail.com>
Message-ID: <CAPJVwBn1-dByQ=CxOQKDed=UEQx64q8qT5mgfkb6XGvjsFq3rA@mail.gmail.com>

On Dec 5, 2017 08:42, "Dustin Ingram" <dustin.ingram at gmail.com> wrote:


Provides-Extra (optional, multiple use)
:::::::::::::::::::::::::::::::::::::::

A string containing the name of an optional feature. Must be a valid Python
identifier. May be used to make a dependency conditional on whether the
optional feature has been requested.

This introduction of this field allows packge installation tools (such as
``pip``) to determine which extras are provided by a given package, and so
that
package publication tools (such as ``twine``) can check for issues with
environment markers which use extras.


I haven't followed this so sorry if this is an annoying comment, but having
read this description I still don't really understand what Provides-Extra
is doing. Don't packages already include extra information? What problem
motivated this?

-n
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171205/abce2a5f/attachment.html>

From p.f.moore at gmail.com  Tue Dec  5 16:16:59 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Tue, 5 Dec 2017 21:16:59 +0000
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CACHw_mQOZox_4eEO8B6zBXtvk6YrUdUtBOW0ZN=GF5pg-0M7gw@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <CACac1F_fVv1MMOunAtziWD0uQVfri1VGzDs923yMPa9d0_+sdA@mail.gmail.com>
 <CACHw_mRhssmtE5d+bTawFLFBxj2PTeTRN8nDQWvz6tfW1vAjHA@mail.gmail.com>
 <CACac1F_fepqGnRrGnYga+qBL4X=6gvpQsJKVpHF3hV3qpnHYuQ@mail.gmail.com>
 <CACHw_mQOZox_4eEO8B6zBXtvk6YrUdUtBOW0ZN=GF5pg-0M7gw@mail.gmail.com>
Message-ID: <CACac1F-EENaet6X=kY42-nS9DX64H3kXVe8X57JUES=BX9a3=w@mail.gmail.com>

On 5 December 2017 at 20:34, Dustin Ingram <di at di.codes> wrote:
> Ah, I see, by "other two" I thought you meant the other two new fields.
>
> Looking at https://www.python.org/dev/peps/pep-0566/ might make it
> more clear that I originally intended the "New in Version 1.3" and
> "Changed in Version 1.3" headings to only be under the "Fields"
> heading, so the outline would be:
>
> * Abstract
> * Fields
>   - New in Version 1.3
>     * Description-Content-Type (optional)
>     * Provides-Extra (optional, multiple use)
>   - Changed in Version 1.3
>     * Name
> * Version Specifiers
> * Environment markers
> * JSON-compatible Metadata
> * Summary of Differences From PEP 345
> * References
> * Copyright
> * Acknowledgements
>
> However I could see the value in inverting this a bit to be:
>
> * Abstract
> * New in Version 1.3
>   - Fields
>     * Description-Content-Type (optional)
>     * Provides-Extra (optional, multiple use)
> * Changed in Version 1.3
>   - Fields
>     * Name
>   - Version Specifiers
>   - Environment markers
>   - JSON-compatible Metadata
> * Summary of Differences From PEP 345
> * References
> * Copyright
> * Acknowledgements
>
> If this is preferable.

Oh! Sorry, I follow now. I'd misunderstood the structure completely -
my mistake. I was thinking of "Version Specifiers" and "Environment
Markers" as fields, when they aren't - they are *part* of certain
fields. The table of contents is completely clear, though, it's just
that I wasn't concentrating so much when I read that.

I'd say it's fine as it stands. Thanks for clarifying.

Paul

From donald at stufft.io  Tue Dec  5 16:39:36 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 5 Dec 2017 16:39:36 -0500
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CAPJVwBn1-dByQ=CxOQKDed=UEQx64q8qT5mgfkb6XGvjsFq3rA@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <CAPJVwB=zewKY5vZVP5d44c6eK_rtp86sp1S59NFZf2B1ebiiPg@mail.gmail.com>
 <CAPJVwBnZ6VKkEVqpOXPLjWPmBALWV-vk-6660gi7-S6tKjQ8sA@mail.gmail.com>
 <CAPJVwB=xFiJBhQi0AQRsag737FK62a93-ROEg8+gSzvOA0y4Yw@mail.gmail.com>
 <CAPJVwB=z=o_kpEy6xT+bdRTzekVSruM-myCYP5Ud2p84pan3Xw@mail.gmail.com>
 <CAPJVwBn1-dByQ=CxOQKDed=UEQx64q8qT5mgfkb6XGvjsFq3rA@mail.gmail.com>
Message-ID: <738DFF0C-71B9-41A0-B884-44E72E0FF58E@stufft.io>



> On Dec 5, 2017, at 4:02 PM, Nathaniel Smith <njs at pobox.com> wrote:
> 
> I haven't followed this so sorry if this is an annoying comment, but having read this description I still don't really understand what Provides-Extra is doing. Don't packages already include extra information? What problem motivated this?


I?m pretty sure this field is literally what wheel already does. https://packaging.python.org/specifications/core-metadata/#provides-extra-optional-multiple-use <https://packaging.python.org/specifications/core-metadata/#provides-extra-optional-multiple-use>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171205/831c4efc/attachment.html>

From ncoghlan at gmail.com  Tue Dec  5 22:33:33 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 6 Dec 2017 13:33:33 +1000
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CAPJVwBn1-dByQ=CxOQKDed=UEQx64q8qT5mgfkb6XGvjsFq3rA@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <CAPJVwB=zewKY5vZVP5d44c6eK_rtp86sp1S59NFZf2B1ebiiPg@mail.gmail.com>
 <CAPJVwBnZ6VKkEVqpOXPLjWPmBALWV-vk-6660gi7-S6tKjQ8sA@mail.gmail.com>
 <CAPJVwB=xFiJBhQi0AQRsag737FK62a93-ROEg8+gSzvOA0y4Yw@mail.gmail.com>
 <CAPJVwB=z=o_kpEy6xT+bdRTzekVSruM-myCYP5Ud2p84pan3Xw@mail.gmail.com>
 <CAPJVwBn1-dByQ=CxOQKDed=UEQx64q8qT5mgfkb6XGvjsFq3rA@mail.gmail.com>
Message-ID: <CADiSq7c2VW_Qb3j0a6=c7HiQmNUtYE_0Z8XhsvhX4aKk42jaPQ@mail.gmail.com>

On 6 December 2017 at 07:02, Nathaniel Smith <njs at pobox.com> wrote:
> On Dec 5, 2017 08:42, "Dustin Ingram" <dustin.ingram at gmail.com> wrote:
>
>
> Provides-Extra (optional, multiple use)
> :::::::::::::::::::::::::::::::::::::::
>
> A string containing the name of an optional feature. Must be a valid Python
> identifier. May be used to make a dependency conditional on whether the
> optional feature has been requested.
>
> This introduction of this field allows packge installation tools (such as
> ``pip``) to determine which extras are provided by a given package, and so
> that
> package publication tools (such as ``twine``) can check for issues with
> environment markers which use extras.
>
>
> I haven't followed this so sorry if this is an annoying comment, but having
> read this description I still don't really understand what Provides-Extra is
> doing. Don't packages already include extra information? What problem
> motivated this?

The main problem it solves is a procedural one related to the fact
that I co-opted Daniel Holth's original metadata 1.3 PEP (i.e. PEP
426) as a more expansive "What if we were designing the metadata
system from scratch?" proposal, which then fell prey to second system
syndrome (https://en.wikipedia.org/wiki/Second-system_effect).

We'd subsequently mitigated that problem by allowing additional fields
to be defined directly in
https://packaging.python.org/specifications/core-metadata/ without
being defined in a PEP, but that turned out to create a new problem
with a lack of adequate transparency in and around the specification
update process.

So Dustin's PEP is aimed mainly at getting things back on track from a
procedural perspective, with
https://packaging.python.org/specifications/ becomes PyPA's equivalent
to the Python Language Reference at
https://docs.python.org/3/reference/, and we use Standards Track PEPs
to justify additions and changes to those specifications, rather than
using Informational PEPs directly as the reference documentation.

As such, PEP 566 doesn't actually *change* the current metadata
specification at the field level - it just takes the existing
post-PEP-345 changes, and formalises them as version 1.3 of the
metadata spec (which should then help with consistency of
implementation across various tools).

The one real change that PEP 566 does propose is a new approach to the
question of defining a JSON-compatible variant of the data format:
rather than designing that from scratch as I did in later versions of
PEP 426 (which would have required major changes for existing tools to
adopt), it instead defines it as a reversible algorithmic
transformation from the existing Key:Value based format, which will
allow new tools to adopt it as their preferred working format, while
still maintaining compatibility with existing tools at the level of
the on-disk file format. (Having that transformation defined in an
interoperability PEP will also allow both Warehouse and
https://packaging.pypa.io/ to implement it, which will be useful when
designing packaging related REST APIs and metadata caching formats).

Cheers,
Nick.

P.S. I'm seriously considering moving PEP 426 and 459 from Deferred to
Withdrawn - while there are still some worthwhile ideas in there, I
think we've learned through experience that the more practical path
forward is to identify specific problems that we can't solve with the
existing interoperability specifications, and then propose concrete
solutions to those problems. While entertaining to explore, "What
would we consider doing if we had unlimited development resources?"
flights of fancy aren't actually a practical approach to making
changes :)

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From sffjunkie+python at gmail.com  Wed Dec  6 07:33:42 2017
From: sffjunkie+python at gmail.com (Simon Kennedy)
Date: Wed, 6 Dec 2017 12:33:42 +0000
Subject: [Distutils] PyPi/Warehouse & User Agent Strings
Message-ID: <CAPQZ5GOanpYb4bQtEH8fdR7TNYfsf0SHLvp3bWzdCKSjBGfRVQ@mail.gmail.com>

A few quick questions about pip/pypi and user agent strings.

Does PyPi/Warehouse do anything with the user agent string or does it just
go into the BigQuery system?
What elements of the user agent string are used?
Is the pip source code the reference document or is there a separate
specification?

---
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171206/14306543/attachment.html>

From sffjunkie+python at gmail.com  Wed Dec  6 09:15:44 2017
From: sffjunkie+python at gmail.com (Simon Kennedy)
Date: Wed, 6 Dec 2017 14:15:44 +0000
Subject: [Distutils] Adding local options to commands
Message-ID: <CAPQZ5GNm9n1wNYpq=s5RpydiBNu0_xzEwiJJH8Z38hEv5MJRyQ@mail.gmail.com>

Is there a recognized way to add options to distutils commands that are
only for my local environment?

For example I stick all my build artifacts in a directory, that is not in
the source directory, and that will not be on the machine of someone who
checks out my code. So I don't want to add it into setup.cfg where it will
get checked in.

For example I set

    bdist-base = ../../build/astral/master/tmp/bdist

that other people won't want it to be written to.

Currently I've created a setup-dev.cfg file and added code to my local
distutils to also look in this file for options.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171206/501ddd9e/attachment.html>

From ncoghlan at gmail.com  Wed Dec  6 09:26:54 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Thu, 7 Dec 2017 00:26:54 +1000
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
Message-ID: <CADiSq7cY=4gOYJ6+J2VdjYTvczJHR-=1Uj8KyC6h3Q-XneiuRw@mail.gmail.com>

On 6 December 2017 at 02:39, Dustin Ingram <dustin.ingram at gmail.com> wrote:
> Hi all,
>
> I'd appreciate your feedback on the following Metadata 1.3 PEP.
>
> The goal here is not to provide a full specification for all fields as
> in previous PEPs, but to:
>
> * Motivate and describe the addition of the new fields or changes to
> existing fields;
> * Point to the Core Metadata Specifications reference document as the
> canonical source for the specification.

Hi folks,

While I'd normally step up as BDFL-Delegate for an interoperability
specification like this one, I'm actually going to be offline for most
of the rest of the year, which I figure wouldn't be especially
conducive to running an effective and timely review process :)

So while I'll note that I'm personally happy with the PEP as it
currently stands (based on my review of Dustin's earlier drafts), I've
also asked Daniel Holth if he'd be willing to handle the task of final
review and approval for this PEP as the original author of the wheel
specification, and Daniel's graciously agreed to do so.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From me at cooperlees.com  Wed Dec  6 12:05:44 2017
From: me at cooperlees.com (Cooper Ry Lees)
Date: Wed, 6 Dec 2017 09:05:44 -0800
Subject: [Distutils] PyPi/Warehouse & User Agent Strings
In-Reply-To: <CAPQZ5GOanpYb4bQtEH8fdR7TNYfsf0SHLvp3bWzdCKSjBGfRVQ@mail.gmail.com>
References: <CAPQZ5GOanpYb4bQtEH8fdR7TNYfsf0SHLvp3bWzdCKSjBGfRVQ@mail.gmail.com>
Message-ID: <8A39BF57-99FE-483F-BE67-1B98072DC067@cooperlees.com>

I don't know what's authoritative, but I can share that it has helped with devpi or bandersnatch having bugs in the past.

Bandersnatch sends something like:
"bandersnatch/2.1.2 (cpython 3.6.3-candidate1, Linux x86_64)"
Code: https://goo.gl/fGgtu8

Cooper

> On Dec 6, 2017, at 4:33 AM, Simon Kennedy <sffjunkie+python at gmail.com> wrote:
> 
> A few quick questions about pip/pypi and user agent strings.
> 
> Does PyPi/Warehouse do anything with the user agent string or does it just go into the BigQuery system?
> What elements of the user agent string are used?
> Is the pip source code the reference document or is there a separate specification?
> 
> ---
> Simon
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171206/5b3b6f9b/attachment.html>

From donald at stufft.io  Thu Dec  7 10:41:37 2017
From: donald at stufft.io (Donald Stufft)
Date: Thu, 7 Dec 2017 10:41:37 -0500
Subject: [Distutils] Outstanding questions for PEP 541: Package Index
 Name Retention
In-Reply-To: <ec31ce21-1c91-460b-83e1-e8acc719bf04@changeset.nyc>
References: <ec31ce21-1c91-460b-83e1-e8acc719bf04@changeset.nyc>
Message-ID: <915A42BD-26AA-468E-A2A2-82946174A4B8@stufft.io>



> On Nov 29, 2017, at 11:10 PM, Sumana Harihareswara <sh at changeset.nyc> wrote:
> 
> While getting up to speed on Warehouse I saw how many package transfer
> requests are waiting for PEP 541[0] to be accepted, so I thought it
> might be helpful to round up what I see as the outstanding questions.
> 
> 1) Usage criteria for abandoned projects.
> 
>> The tricky part there is that "being used" is a tough concept to 
>> define. Over what time period? What amount of downloading counts as 
>> "used"?-- Chris Rose[1]
> 
> Perhaps a month? suggests Matthias Bussonnier.[2]
> 
> The ensuing discussion includes thoughts on locking old versions of the
> project[3]; as I see it, that's a potential feature request for
> Warehouse, but not something to build into this PEP. (Similarly, Nick
> Timkovich's idea of "salting" hot-button names on PyPI so it isn't
> possible to register projects like "android"[4] is a feature idea I like
> but I think this PEP does not need to wait for it.)


A month seems reasonable to me, though I don?t know how much we can or should define ?being used?. For instance, every package in existence is going to be downloaded via mirroring, so we can?t go by pure download counts (and some mirrors just use pip to do their downloading) and we?re going to need to interpret the download counts to some degree to try and gauge ?usage?.

Ultimately I think the underlying question we?re answering is whether names on PyPI are a community good or a personal good, and this PEP more or less states they are a community good and attempts to outlay the situations in which it is good for the community to have a name reassigned. Given that, I think the guideline of ?not being used over a month? is a reasonable one, and that lets the admins interpret the download counts in that light.


> 
> 2) A few copyedits from Chris Barker.[5]
> 
> 3) "How would I, for example, start the process of flagging a
> project as abandoned?" -- Nick Timkovich[6]
> 
> It seems to me that the PEP's wording in "Removal of an abandoned
> project" says we'll allow transfer of abandoned projects but will not
> remove them only for being abandoned. However, the PEP currently doesn't
> include a "where to file a ticket" line in that section (as it does in
> "Invalid projects"). Also, if there's some other reason we should be
> willing to remove abandoned projects even without a transfer, e.g., the
> project has a critical security flaw, we should say that somewhere in
> this PEP or in a different policy document.


I do not think the PEP needs to include this, since the PEP itself won?t be the end user facing documentation for this, but is rather the proposal that this is how we do these things, and there will be a page on PyPI that has user facing policy sans rationale, history, etc that will also include stuff like actual procedure for contacting admins to get something looked at under this policy.


> 
> There is one item ?ukasz mentioned this in the "I decided to not
> otherwise touch on:" list regarding the revision on January 14th[7] that
> I think deserves one more chance for discussion. :) A few people brought
> up making the reachability criteria and instructions crisper.


Generally I think that package authors should be responsible for ensuring that there is some mechanism on PyPI that we can use to communicate with them. I?m down with adding more features to Warehouse to make this more likely, but ultimately I think it boils down to authors should expect to have an email on file with PyPI we can reach them at for important communication, or they should not be surprised when things happen they were not aware of.


> 
>> Regarding reachability: contact attempts should also include the 
>> relevant project's issue tracker if attempts at private contact have 
>> failed.
>> 
>> This step is important as it allows a project's *user* community to 
>> respond, even if the person that actually pushes the buttons to 
>> upload new releases to PyPI is out of contact for some reason.
> -- Nick Coghlan[8]
> 
> Nick Timkovich also suggested some specific instructions[9] that would
> help set expectations to, among other things, reassure maintainers about
> the length of offline vacations they can take without worrying about
> having their packages usurped. :)
> 
> I'm totally fine with folks saying to me: no, these are all addressed,
> or not important enough to slow adoption of this PEP. In which case,
> yay, I hope Donald can accept it and we can start processing the backlog.

The current timeline is 6 weeks, so that is effectively the window that people are expected to be available sometime every 6 weeks. I don?t have a good sense for if that is reasonable or not, if people think it should be longer we can easily do longer. My personal life I rarely take any vacation or am unavailable for rarely more than 24h, so for me personally 6 weeks would be an eternity, but if folks feel that a 6+ week vacation is something we want to support, then we can trivially adjust this upwards.


> 
> 
> [0] https://www.python.org/dev/peps/pep-0541/
> [1] https://mail.python.org/pipermail/distutils-sig/2017-January/030017.html
> [2] https://mail.python.org/pipermail/distutils-sig/2017-January/030020.html
> [3] https://mail.python.org/pipermail/distutils-sig/2017-January/030034.html
> [4] https://mail.python.org/pipermail/distutils-sig/2017-January/030006.html
> [5]
> https://mail.python.org/pipermail/distutils-sig/2017-September/031517.html
> [6] https://mail.python.org/pipermail/distutils-sig/2017-January/030005.html
> [7] https://mail.python.org/pipermail/distutils-sig/2017-January/030009.html
> [8] https://mail.python.org/pipermail/distutils-sig/2017-January/030008.html
> [9] https://mail.python.org/pipermail/distutils-sig/2017-January/030005.html
> 
> -- 
> Sumana Harihareswara
> Changeset Consulting
> https://changeset.nyc
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig


From sh at changeset.nyc  Thu Dec  7 11:44:03 2017
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Thu, 7 Dec 2017 11:44:03 -0500
Subject: [Distutils] Update on Warehouse kickoff and milestones
Message-ID: <a2b95ec0-86ba-b56e-5a9a-9f3fa6fef59c@changeset.nyc>

As Donald and Nick mentioned last month,[0] several folks are -- thanks
to Mozilla Open Source Support -- working on deploying Warehouse and
making PyPI more sustainable. I'm the main project manager on this
effort and am putting notes on wiki.python.org as we go.[1]

Ernest W. Durbin III gave the closing talk at North Bay Python a few
days ago: "Running Vintage Software: PyPI's Aging Codebase."[2] As he
mentioned (video[3]), he's one of the people who'll be working on this
project, funded by MOSS, to get Warehouse across the finish line! The
full cast is:

* Donald Stufft, backend
* Dustin Ingram, backend
* Ernest W. Durbin III, backend
* Laura Hampton, project management, testing, documentation
* Nicole Harris, frontend and design
* Sumana Harihareswara, project management, product management, testing,
documentation

None of us are working 40 hours/week on this but the six people I listed
above are dedicating committed time to the work. And we're grateful for
help from Mark Mangoba, Eric Holscher, and of course several other folks
who are involved in the PSF, PyPA, or MOSS.

We had a kickoff call on Monday[4] and today a few of us spoke in
#pypa-dev and fleshed out our milestones[5] a bit. This may still
change, but right now, the sequence is:

 1. Maintainer Minimum Viable Product (for package owners) -- ask some
maintainers to use, test, and report back
 2. End User MVP -- ask some Python users who aren't package owners to
use Warehouse, test, and report back
 3. Publicize beta more broadly (invite more testing, redirect some `pip
install` traffic)
 4. Launch/redirect `pip` and browsers to Warehouse
 5. Shut down legacy PyPI
 6. Cool feature ideas that are not on critical path

We'll be putting issues about infrastructure work (e.g., Kubernetes) in
https://github.com/python/pypi-infra . We've started filing, updating,
and arranging issues but that isn't yet complete enough for me to even
start making schedule estimates. I aim to have a clearer picture next
week. (I won't spam this list with updates when there's nothing new to
say, but at least as we start I figure you might want news a few times a
month to learn how things are shaping up; please let me know privately
if my estimation there is way off.)


[0]
https://mail.python.org/pipermail/distutils-sig/2017-November/031782.html
[1] https://wiki.python.org/psf/PackagingWG
[2] https://2017.northbaypython.org/schedule/presentation/5/
[3] https://www.youtube.com/watch?v=xyPd4WOR_ng
[4] https://wiki.python.org/psf/PackagingWG/2017-12-04-Warehouse
[5] https://github.com/pypa/warehouse/milestones
-- 
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc

From chris.barker at noaa.gov  Thu Dec  7 12:01:44 2017
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Thu, 7 Dec 2017 09:01:44 -0800
Subject: [Distutils] Outstanding questions for PEP 541: Package Index
 Name Retention
In-Reply-To: <915A42BD-26AA-468E-A2A2-82946174A4B8@stufft.io>
References: <ec31ce21-1c91-460b-83e1-e8acc719bf04@changeset.nyc>
 <915A42BD-26AA-468E-A2A2-82946174A4B8@stufft.io>
Message-ID: <-222902321308070907@unknownmsgid>

> I don?t know how much we can or should define ?being used?. For instance,
every package in existence is going to be downloaded via mirroring, so we
can?t go by pure download counts (and some mirrors just use pip to do their
downloading) and we?re going to need to interpret the download counts to
some degree to try and gauge ?usage?.

One idea? create a couple of ?dummy? packages that do absolutely nothing.
Then the download counts on those would give you a baseline for ?downloaded
but not used?

-CHB

Ultimately I think the underlying question we?re answering is whether names
on PyPI are a community good or a personal good, and this PEP more or less
states they are a community good


Which they absolutely are. PyPi is a community project ? the names on pypi
are just that ? names on pypi. If you don?t want to be part of that
community, you can use any name you want.

-CHB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171207/64056b8a/attachment.html>

From barry at python.org  Thu Dec  7 12:26:58 2017
From: barry at python.org (Barry Warsaw)
Date: Thu, 07 Dec 2017 12:26:58 -0500
Subject: [Distutils] Multiple package authors
Message-ID: <p0btks$b75$1@blaine.gmane.org>

I think I implicitly knew this, but as I've just released a package (to
be announced soon) that actually has multiple authors, I found out first
hand that PyPI rejects uploads where the author-email field isn't a
completely valid email address, and that there is no support for
multiple author emails.

As it turns out, you can kludge this into your pyproject.toml or
setup.py file.  flit for example separates multiple emails with a
newline, but you could also separate them with commas.  You don't notice
the problem until PyPI rejects the upload (with a 400 IIRC).

I filed this issue with flit: https://github.com/takluyver/flit/issues/153

It looks like Thomas agrees that at least flit will eventually validate
its fields so you error early.  It was a bit of a PITA to do my upload
because I didn't notice the problem until after I'd tagged the repo.

Multiple package authors doesn't seem like that fringe of a use case;
are there any plans, documents, PEPs, musings, grumbles about supporting
multiple package authors explicitly?

Cheers,
-Barry


From wes.turner at gmail.com  Thu Dec  7 13:17:28 2017
From: wes.turner at gmail.com (Wes Turner)
Date: Thu, 7 Dec 2017 13:17:28 -0500
Subject: [Distutils] Multiple package authors
In-Reply-To: <p0btks$b75$1@blaine.gmane.org>
References: <p0btks$b75$1@blaine.gmane.org>
Message-ID: <CACfEFw8M1E0a0M=YZtHyCkEmtdd9M1=z5rbvqutk39x8NVh=8w@mail.gmail.com>

There are author-email and maintainer-email fields.

You could also or instead use a mailing list address for the author-email
or maintainer-email fields. Newlines work (just like file\nnames)?

With a mailing list, package maintainers can share responsibility (*) and
hand off correspondence without forwards and indentation.

Google Groups is free; are there alternatives:
https://support.google.com/groups/answer/2464926

You can use a third party service to create e.g. GitHub or GitLab issues
via email; however, security sensitive information (vulnerabilities,
credentials, personal information) may require additional caution and
admonitions.

If not otherwise specified in the long description, presumably the
author-email and/or maintainer-email address(es) are the correct place to
send fair disclosure information.

This could be a separate thread/issue and an additional package metadata
field maybe for Package Metadata 1.3? Sorry, a BIT OT.

security-email?

On Thursday, December 7, 2017, Barry Warsaw <barry at python.org> wrote:

> I think I implicitly knew this, but as I've just released a package (to
> be announced soon) that actually has multiple authors, I found out first
> hand that PyPI rejects uploads where the author-email field isn't a
> completely valid email address, and that there is no support for
> multiple author emails.
>
> As it turns out, you can kludge this into your pyproject.toml or
> setup.py file.  flit for example separates multiple emails with a
> newline, but you could also separate them with commas.  You don't notice
> the problem until PyPI rejects the upload (with a 400 IIRC).
>
> I filed this issue with flit: https://github.com/takluyver/flit/issues/153
>
> It looks like Thomas agrees that at least flit will eventually validate
> its fields so you error early.  It was a bit of a PITA to do my upload
> because I didn't notice the problem until after I'd tagged the repo.
>
> Multiple package authors doesn't seem like that fringe of a use case;
> are there any plans, documents, PEPs, musings, grumbles about supporting
> multiple package authors explicitly?
>
> Cheers,
> -Barry
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171207/b9c04a3b/attachment.html>

From wes.turner at gmail.com  Thu Dec  7 13:23:24 2017
From: wes.turner at gmail.com (Wes Turner)
Date: Thu, 7 Dec 2017 13:23:24 -0500
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CADiSq7cY=4gOYJ6+J2VdjYTvczJHR-=1Uj8KyC6h3Q-XneiuRw@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <CADiSq7cY=4gOYJ6+J2VdjYTvczJHR-=1Uj8KyC6h3Q-XneiuRw@mail.gmail.com>
Message-ID: <CACfEFw-JY1g6r0w6hYYcxJ+OF-C-HtHpdX1jLz_X_YsAriGzrA@mail.gmail.com>

>From "[distutils] Multiple package authors" [1]

- How should multiple author-email and maintainer-email addresses be
specified?

- Should we add security-email and/or security-disclosure-instructions?


[1] http://markmail.org/thread/xmwfktnsbmpakv6b

On Wednesday, December 6, 2017, Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 6 December 2017 at 02:39, Dustin Ingram <dustin.ingram at gmail.com>
> wrote:
> > Hi all,
> >
> > I'd appreciate your feedback on the following Metadata 1.3 PEP.
> >
> > The goal here is not to provide a full specification for all fields as
> > in previous PEPs, but to:
> >
> > * Motivate and describe the addition of the new fields or changes to
> > existing fields;
> > * Point to the Core Metadata Specifications reference document as the
> > canonical source for the specification.
>
> Hi folks,
>
> While I'd normally step up as BDFL-Delegate for an interoperability
> specification like this one, I'm actually going to be offline for most
> of the rest of the year, which I figure wouldn't be especially
> conducive to running an effective and timely review process :)
>
> So while I'll note that I'm personally happy with the PEP as it
> currently stands (based on my review of Dustin's earlier drafts), I've
> also asked Daniel Holth if he'd be willing to handle the task of final
> review and approval for this PEP as the original author of the wheel
> specification, and Daniel's graciously agreed to do so.
>
> Regards,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171207/5b9934fe/attachment-0001.html>

From barry at python.org  Thu Dec  7 16:31:11 2017
From: barry at python.org (Barry Warsaw)
Date: Thu, 07 Dec 2017 16:31:11 -0500
Subject: [Distutils] Multiple package authors
In-Reply-To: <CACfEFw8M1E0a0M=YZtHyCkEmtdd9M1=z5rbvqutk39x8NVh=8w@mail.gmail.com>
References: <p0btks$b75$1@blaine.gmane.org>
 <CACfEFw8M1E0a0M=YZtHyCkEmtdd9M1=z5rbvqutk39x8NVh=8w@mail.gmail.com>
Message-ID: <p0cbuo$fjm$1@blaine.gmane.org>

Wes Turner wrote:
> There are author-email and maintainer-email fields.
> 
> You could also or instead use a mailing list address for the author-email
> or maintainer-email fields. Newlines work (just like file\nnames)?
> 
> With a mailing list, package maintainers can share responsibility (*) and
> hand off correspondence without forwards and indentation.

Oh, I know there are workarounds, but that's not the point.  I think it
would generally make sense to support multiple authors directly, since
collaboration is a common pattern.

Cheers
-Barry



From thomas at kluyver.me.uk  Fri Dec  8 11:42:42 2017
From: thomas at kluyver.me.uk (Thomas Kluyver)
Date: Fri, 08 Dec 2017 16:42:42 +0000
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
Message-ID: <1512751362.3013985.1198669584.190D654F@webmail.messagingengine.com>

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 tools
writing dependency specifications should not create them. Its
recommended format is therefore "zope.interface >3.5.0".

Should the metadata 1.3 PEP note that this has changed? Or do we only
need to update the metadata spec on PyPUG?

(I'm writing some validation code for flit, and quickly seeing the value
in having the latest information in one place, rather than scattered
across several PEPs)

Thomas

On Tue, Dec 5, 2017, at 04:39 PM, Dustin Ingram wrote:
> Hi all,
> 
> I'd appreciate your feedback on the following Metadata 1.3 PEP.
> 
> The goal here is not to provide a full specification for all fields as
> in previous PEPs, but to:
> 
> * Motivate and describe the addition of the new fields or changes to
> existing fields;
> * Point to the Core Metadata Specifications reference document as the
> canonical source for the specification.
> 
> Previous discussions:
> *
> https://mail.python.org/pipermail/distutils-sig/2017-September/031465.html
> * https://github.com/python/peps/issues/388
> 
> Thanks,
> D.
> 
> 
> PEP: 566
> Title: Metadata for Python Software Packages 1.3
> Version: $Revision$
> Last-Modified: $Date$
> Author: Dustin Ingram <di at di.codes>
> Discussions-To: distutils-sig <distutils-sig at python.org>
> Status: Draft
> Type: Standards Track
> Content-Type: text/x-rst
> Created: 1-Dec-2017
> Python-Version: 3.x
> Post-History:
> Replaces: 345
> 
> 
> Abstract
> ========
> 
> This PEP describes the changes between versions 1.2 and 1.3 of the core
> metadata specification for Python packages. Version 1.2 is specified in
> PEP
> 345.
> 
> It also changes to the canonical source for field specifications to the
> `Core
> Metadata Specification`_ reference document, which includes specifics of
> the
> field names, and their semantics and usage.
> 
> Fields
> ======
> 
> The canonical source for the names and semantics of each of the supported
> metadata fields is the `Core Metadata Specification`_ document.
> 
> Fields marked with "(Multiple use)" may be specified multiple times in a
> single
> PKG-INFO file.  Other fields may only occur once in a PKG-INFO file. 
> Fields
> marked with "(optional)" are not required to appear in a valid PKG-INFO
> file;
> all other fields must be present.
> 
> New in Version 1.3
> ------------------
> 
> Description-Content-Type (optional)
> :::::::::::::::::::::::::::::::::::
> 
> A string stating the markup syntax (if any) used in the distribution's
> description, so that tools can intelligently render the description.
> 
> Historically, tools like PyPI assume that a package's description is
> formatted
> in `reStructuredText (reST)
> <http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html>`_,
> and
> fall back on plain text if the description is not valid reST.
> 
> The introduction of this field allows PyPI to support additional types of
> markup syntax, and not need to make this assumption.
> 
> The full specification for this field is defined in the `Core Metadata
> Specification`_.
> 
> 
> Provides-Extra (optional, multiple use)
> :::::::::::::::::::::::::::::::::::::::
> 
> A string containing the name of an optional feature. Must be a valid
> Python
> identifier. May be used to make a dependency conditional on whether the
> optional feature has been requested.
> 
> This introduction of this field allows packge installation tools (such as
> ``pip``) to determine which extras are provided by a given package, and
> so that
> package publication tools (such as ``twine``) can check for issues with
> environment markers which use extras.
> 
> The full specification for this field is defined in the `Core Metadata
> Specification`_.
> 
> Changed in Version 1.3
> ----------------------
> 
> Name
> ::::
> 
> The specification for the format of this field is now identical to the
> distribution name specification defined in PEP 508.
> 
> Version Specifiers
> ==================
> 
> Version numbering requirements and the semantics for specifying
> comparisons
> between versions are defined in PEP 440.
> 
> Environment markers
> ===================
> 
> An **environment marker** is a marker that can be added at the end of a
> field after a semi-colon (";"), to add a condition about the execution
> environment.
> 
> The environment marker format used to declare such a condition is defined
> in
> the environment markers section of PEP 508.
> 
> JSON-compatible Metadata
> ========================
> 
> It may be necessary to store metadata in a data structure which does not
> allow for multiple repeated keys, such as JSON.
> 
> The canonical method to transform metadata fields into such a data
> structure is
> as follows:
> 
> #. The original key-value format should be read with
>    ``email.parser.HeaderParser``;
> #. All transformed keys should be reduced to lower case, but otherwise
> should
>    retain all other characters;
> #. The transformed value for any field marked with "(Multiple-use")
> should be a
>    single list containing all the original values for the given key;
> #. The ``Keywords`` field should be converted to a list by splitting the
>    original value on whitespace characters;
> #. The result should be stored as a string-keyed dictionary.
> 
> Summary of Differences From PEP 345
> ===================================
> 
> * Metadata-Version is now 1.3.
> 
> * Fields are now specified via the `Core Metadata Specification`_.
> 
> * Added two new fields: ``Description-Content-Type`` and
> ``Provides-Extra``
> 
> * Acceptable values for the ``Name`` field are now specified as per PEP
> 508.
> 
> * Added canonical method of transformation into JSON-compatible data
> structure.
> 
> References
> ==========
> 
> This document specifies version 1.3 of the metadata format.
> Version 1.0 is specified in PEP 241.
> Version 1.1 is specified in PEP 314.
> Version 1.2 is specified in PEP 345.
> 
> .. _`Core Metadata Specification`:
>    https://packaging.python.org/specifications/core-metadata/
> 
> Copyright
> =========
> 
> This document has been placed in the public domain.
> 
> Acknowledgements
> ================
> 
> Thanks to Nick Colgan for contributing to this PEP.
> 
> 
> ..
>    Local Variables:
>    mode: indented-text
>    indent-tabs-mode: nil
>    sentence-end-double-space: t
>    fill-column: 80
>    End:
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

From ncoghlan at gmail.com  Sat Dec  9 02:02:41 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 9 Dec 2017 17:02:41 +1000
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <1512751362.3013985.1198669584.190D654F@webmail.messagingengine.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <1512751362.3013985.1198669584.190D654F@webmail.messagingengine.com>
Message-ID: <CADiSq7eHbN5EGaZRCLP5JasP4cBrZ4pLcTjfZ28Fmx4mX91bcQ@mail.gmail.com>

On 9 December 2017 at 02:42, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> 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 tools
> writing dependency specifications should not create them. Its
> recommended format is therefore "zope.interface >3.5.0".
>
> Should the metadata 1.3 PEP note that this has changed? Or do we only
> need to update the metadata spec on PyPUG?

The new PEP already delegates to PEP 508 for the version specifier
format, so I think that can just be updated in PyPUG.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

From dholth at gmail.com  Sat Dec  9 09:27:12 2017
From: dholth at gmail.com (Daniel Holth)
Date: Sat, 09 Dec 2017 14:27:12 +0000
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CADiSq7eHbN5EGaZRCLP5JasP4cBrZ4pLcTjfZ28Fmx4mX91bcQ@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <1512751362.3013985.1198669584.190D654F@webmail.messagingengine.com>
 <CADiSq7eHbN5EGaZRCLP5JasP4cBrZ4pLcTjfZ28Fmx4mX91bcQ@mail.gmail.com>
Message-ID: <CAG8k2+50B63fTu+7n0msOeLnJo1Hct-iShwKb0h2UoEtmJAQjQ@mail.gmail.com>

I don't know why the parentheses were included in the older pep. They are
widely deployed. We probably can get rid of them or make them optional in a
practical parser.

On Sat, Dec 9, 2017, 02:03 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 9 December 2017 at 02:42, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
> > 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 tools
> > writing dependency specifications should not create them. Its
> > recommended format is therefore "zope.interface >3.5.0".
> >
> > Should the metadata 1.3 PEP note that this has changed? Or do we only
> > need to update the metadata spec on PyPUG?
>
> The new PEP already delegates to PEP 508 for the version specifier
> format, so I think that can just be updated in PyPUG.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171209/07ea5f94/attachment.html>

From di at di.codes  Mon Dec 11 18:19:47 2017
From: di at di.codes (Dustin Ingram)
Date: Mon, 11 Dec 2017 17:19:47 -0600
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CAG8k2+50B63fTu+7n0msOeLnJo1Hct-iShwKb0h2UoEtmJAQjQ@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <1512751362.3013985.1198669584.190D654F@webmail.messagingengine.com>
 <CADiSq7eHbN5EGaZRCLP5JasP4cBrZ4pLcTjfZ28Fmx4mX91bcQ@mail.gmail.com>
 <CAG8k2+50B63fTu+7n0msOeLnJo1Hct-iShwKb0h2UoEtmJAQjQ@mail.gmail.com>
Message-ID: <CACHw_mTQoodr1_Ttf+gzisUQrfH1bMxMxn0KqMfzFvrkQH4Z3A@mail.gmail.com>

After working a bit on an implementation of the "JSON-compatible
Metadata" section in this PEP, I'm noticing that it might be more
useful if it had the following step instead for canonicalizing the
field names:

> #. All transformed keys should be reduced to lower case. Hyphens should be
>    replaced with underscores, but otherwise should retain all other characters;

Thus a field like `Description-Content-Type` would become
`description_content_type` and the resulting data structure would be
slightly more useful (as it could be passed as `**kwargs` to a
function with PEP 8 style parameter names)

If no one has any objections to this, I'll update the draft accordingly.

Also, if there is no other feedback on the current draft, I'l be
formally submitting it for Daniel's review this week.

Thanks,
D.

On Sat, Dec 9, 2017 at 8:27 AM, Daniel Holth <dholth at gmail.com> wrote:
> I don't know why the parentheses were included in the older pep. They are
> widely deployed. We probably can get rid of them or make them optional in a
> practical parser.
>
>
> On Sat, Dec 9, 2017, 02:03 Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> On 9 December 2017 at 02:42, Thomas Kluyver <thomas at kluyver.me.uk> wrote:
>> > 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 tools
>> > writing dependency specifications should not create them. Its
>> > recommended format is therefore "zope.interface >3.5.0".
>> >
>> > Should the metadata 1.3 PEP note that this has changed? Or do we only
>> > need to update the metadata spec on PyPUG?
>>
>> The new PEP already delegates to PEP 508 for the version specifier
>> format, so I think that can just be updated in PyPUG.
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>> _______________________________________________
>> Distutils-SIG maillist  -  Distutils-SIG at python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>

From wes.turner at gmail.com  Mon Dec 11 18:41:18 2017
From: wes.turner at gmail.com (Wes Turner)
Date: Mon, 11 Dec 2017 18:41:18 -0500
Subject: [Distutils] RFC: PEP 566 - Metadata for Python Software
 Packages 1.3
In-Reply-To: <CACHw_mTQoodr1_Ttf+gzisUQrfH1bMxMxn0KqMfzFvrkQH4Z3A@mail.gmail.com>
References: <CACHw_mTyzfVsDF+hnQr_1pdPEHoPoWYni++s5v5-WjV0H6dXWA@mail.gmail.com>
 <1512751362.3013985.1198669584.190D654F@webmail.messagingengine.com>
 <CADiSq7eHbN5EGaZRCLP5JasP4cBrZ4pLcTjfZ28Fmx4mX91bcQ@mail.gmail.com>
 <CAG8k2+50B63fTu+7n0msOeLnJo1Hct-iShwKb0h2UoEtmJAQjQ@mail.gmail.com>
 <CACHw_mTQoodr1_Ttf+gzisUQrfH1bMxMxn0KqMfzFvrkQH4Z3A@mail.gmail.com>
Message-ID: <CACfEFw-oiYCi_+unC-MqfFsZ7hZbs7FD-4zqYuqij06zP3=EJA@mail.gmail.com>

On Monday, December 11, 2017, Dustin Ingram <di at di.codes> wrote:

> After working a bit on an implementation of the "JSON-compatible
> Metadata" section in this PEP, I'm noticing that it might be more
> useful if it had the following step instead for canonicalizing the
> field names:
>
> > #. All transformed keys should be reduced to lower case. Hyphens should
> be
> >    replaced with underscores, but otherwise should retain all other
> characters;
>
> Thus a field like `Description-Content-Type` would become
> `description_content_type` and the resulting data structure would be
> slightly more useful (as it could be passed as `**kwargs` to a
> function with PEP 8 style parameter names)


Good idea.


>
> If no one has any objections to this, I'll update the draft accordingly.
>
> Also, if there is no other feedback on the current draft, I'l be
> formally submitting it for Daniel's review this week.


(Copied and pasted this from above)

>From "[distutils] Multiple package authors" [1]

- How should multiple author-email and maintainer-email addresses be
specified?

- Should we add security-email and/or security-disclosure-instructions?


[1] http://markmail.org/thread/xmwfktnsbmpakv6b


>
> Thanks,
> D.
>
> On Sat, Dec 9, 2017 at 8:27 AM, Daniel Holth <dholth at gmail.com> wrote:
> > I don't know why the parentheses were included in the older pep. They are
> > widely deployed. We probably can get rid of them or make them optional
> in a
> > practical parser.
> >
> >
> > On Sat, Dec 9, 2017, 02:03 Nick Coghlan <ncoghlan at gmail.com> wrote:
> >>
> >> On 9 December 2017 at 02:42, Thomas Kluyver <thomas at kluyver.me.uk>
> wrote:
> >> > 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 tools
> >> > writing dependency specifications should not create them. Its
> >> > recommended format is therefore "zope.interface >3.5.0".
> >> >
> >> > Should the metadata 1.3 PEP note that this has changed? Or do we only
> >> > need to update the metadata spec on PyPUG?
> >>
> >> The new PEP already delegates to PEP 508 for the version specifier
> >> format, so I think that can just be updated in PyPUG.
> >>
> >> Cheers,
> >> Nick.
> >>
> >> --
> >> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> >> _______________________________________________
> >> Distutils-SIG maillist  -  Distutils-SIG at python.org
> >> https://mail.python.org/mailman/listinfo/distutils-sig
> >
> >
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
> >
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171211/48d1b2df/attachment.html>

From barry at python.org  Wed Dec 13 19:17:43 2017
From: barry at python.org (Barry Warsaw)
Date: Wed, 13 Dec 2017 19:17:43 -0500
Subject: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses
Message-ID: <p0sfv1$5c2$1@blaine.gmane.org>

I'm about to release a new version of importlib_resources, so I want to
get my flit.ini's require-python clause right.  We support Python 2.7,
and 3.4 and beyond.  This makes me sad:

requires-python = '>=2.7,!=3.0,!=3.1,!=3.2,!=3.3'

Of course, I'd like to write this like:

requires-python = '(>=2.7 and <3) or >= 3.4'

I understand that OR clauses aren't supported under any syntax
currently, but as PEPs 566 and 508 are still open/active, wouldn't it be
reasonable to support something like this explicitly?

It seems like wanting to support 2.7 and some versions of Python 3 (but
not all) is a fairly common need.

Cheers,
-Barry


From di at di.codes  Wed Dec 13 19:39:39 2017
From: di at di.codes (Dustin Ingram)
Date: Wed, 13 Dec 2017 18:39:39 -0600
Subject: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses
In-Reply-To: <p0sfv1$5c2$1@blaine.gmane.org>
References: <p0sfv1$5c2$1@blaine.gmane.org>
Message-ID: <CACHw_mT-ewtq1PVdZ8-BXeHzvjt+S-HkprY0KvSPwVAbYsUJfA@mail.gmail.com>

It seems like a small amount of convenience in exchange for a
significant increase in complexity to me.

FYI, some previous discussion on the topic can be found here:

  https://mail.python.org/pipermail/distutils-sig/2016-September/029651.html

And also here:

  https://github.com/pypa/setuptools/issues/1158

D.

On Wed, Dec 13, 2017 at 6:17 PM, Barry Warsaw <barry at python.org> wrote:
> I'm about to release a new version of importlib_resources, so I want to
> get my flit.ini's require-python clause right.  We support Python 2.7,
> and 3.4 and beyond.  This makes me sad:
>
> requires-python = '>=2.7,!=3.0,!=3.1,!=3.2,!=3.3'
>
> Of course, I'd like to write this like:
>
> requires-python = '(>=2.7 and <3) or >= 3.4'
>
> I understand that OR clauses aren't supported under any syntax
> currently, but as PEPs 566 and 508 are still open/active, wouldn't it be
> reasonable to support something like this explicitly?
>
> It seems like wanting to support 2.7 and some versions of Python 3 (but
> not all) is a fairly common need.
>
> Cheers,
> -Barry
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

From donald at stufft.io  Wed Dec 13 19:54:41 2017
From: donald at stufft.io (Donald Stufft)
Date: Wed, 13 Dec 2017 19:54:41 -0500
Subject: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses
In-Reply-To: <p0sfv1$5c2$1@blaine.gmane.org>
References: <p0sfv1$5c2$1@blaine.gmane.org>
Message-ID: <0F1FEED6-A0F9-477B-B459-BDBE5BE62C50@stufft.io>


> On Dec 13, 2017, at 7:17 PM, Barry Warsaw <barry at python.org> wrote:
> 
> I understand that OR clauses aren't supported under any syntax
> currently, but as PEPs 566 and 508 are still open/active, wouldn't it be
> reasonable to support something like this explicitly?


I personally think this is a good idea, and ideally it would come with support ?and?, ?or?, and parenthetical for grouping and deprecate (but not remove) support for comma as and and. We actually already support this inside of environment markers just not in the version specifiers. So you can do something like ``python_version == ?2.7? or python_version >= ?3.4?`` in environment markers and that works but it doesn?t work in other scenarios where it?s useful (such as in requires_python).

Overall I?m +1, not sure if it would be a new PEP or an amendment to the current PEPs but I think it?s a good idea.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171213/52ffc664/attachment.html>

From barry at python.org  Wed Dec 13 20:56:52 2017
From: barry at python.org (Barry Warsaw)
Date: Wed, 13 Dec 2017 20:56:52 -0500
Subject: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses
In-Reply-To: <CACHw_mT-ewtq1PVdZ8-BXeHzvjt+S-HkprY0KvSPwVAbYsUJfA@mail.gmail.com>
References: <p0sfv1$5c2$1@blaine.gmane.org>
 <CACHw_mT-ewtq1PVdZ8-BXeHzvjt+S-HkprY0KvSPwVAbYsUJfA@mail.gmail.com>
Message-ID: <66CADB41-1BAA-4C92-BE08-CF3C0B4269F8@python.org>

On Dec 13, 2017, at 19:39, Dustin Ingram <di at di.codes> wrote:
> 
> It seems like a small amount of convenience in exchange for a
> significant increase in complexity to me.

I can?t speak to the complexity, but it?s very definitely an important use case.  Imagine when Python 3.10 is out; do you really want to have to write:

requires-python = '>=2.7,!=3.0,!=3.1,!=3.2,!=3.3,!=3.4,!=3.5,!=3.6,!=3.7?

and so on?  Plus, I don?t think it?s uncommon to have disjointed version support like this (well, maybe until 2020 when Python 2 is dead and gone <wink>).  And you have to get requires-python right, otherwise tools like tox can?t do the right thing when they install your library into its virtual environments.

> FYI, some previous discussion on the topic can be found here:

Thanks for the links.

And thanks Donald for your vote of support.

Cheers,
-Barry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171213/0513639e/attachment.sig>

From vano at mail.mipt.ru  Wed Dec 13 21:11:32 2017
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Thu, 14 Dec 2017 05:11:32 +0300
Subject: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses
In-Reply-To: <p0sfv1$5c2$1@blaine.gmane.org>
References: <p0sfv1$5c2$1@blaine.gmane.org>
Message-ID: <7d4bced7-355d-1a3c-9fb1-813da5d01078@mail.mipt.ru>



On 14.12.2017 3:17, Barry Warsaw wrote:
> I'm about to release a new version of importlib_resources, so I want to
> get my flit.ini's require-python clause right.  We support Python 2.7,
> and 3.4 and beyond.  This makes me sad:
>
> requires-python = '>=2.7,!=3.0,!=3.1,!=3.2,!=3.3'
>
> Of course, I'd like to write this like:
>
> requires-python = '(>=2.7 and <3) or >= 3.4'
>
> I understand that OR clauses aren't supported under any syntax
> currently, but as PEPs 566 and 508 are still open/active, wouldn't it be
> reasonable to support something like this explicitly?
>
> It seems like wanting to support 2.7 and some versions of Python 3 (but
> not all) is a fairly common need.
What you're actually asking for is for the >= operator to be limited to 
a specified major version.

With semantic versioning (which is Python's recommended best practice), 
this is actually a very reasonable thing to do:
specify supported major versions, and for each one (it's more likely to 
be the edge ones), optionally limit minor versions.

If only we could think of a good syntax...

Folks, how problematic would it be to make this the default/enabled with 
a switch?
With only two major versions, I don't expect much breakage, except 
packages like setuptools that don't use semantic versioning.

-- 
Regards,
Ivan


From njs at pobox.com  Wed Dec 13 21:25:32 2017
From: njs at pobox.com (Nathaniel Smith)
Date: Wed, 13 Dec 2017 18:25:32 -0800
Subject: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses
In-Reply-To: <7d4bced7-355d-1a3c-9fb1-813da5d01078@mail.mipt.ru>
References: <p0sfv1$5c2$1@blaine.gmane.org>
 <7d4bced7-355d-1a3c-9fb1-813da5d01078@mail.mipt.ru>
Message-ID: <CAPJVwB=1gX2KiiYRsPnxF31YrSphBzHV+1yksTsKpK02AEstCA@mail.gmail.com>

On Wed, Dec 13, 2017 at 6:11 PM, Ivan Pozdeev via Distutils-SIG
<distutils-sig at python.org> wrote:
>
>
> On 14.12.2017 3:17, Barry Warsaw wrote:
>>
>> I'm about to release a new version of importlib_resources, so I want to
>> get my flit.ini's require-python clause right.  We support Python 2.7,
>> and 3.4 and beyond.  This makes me sad:
>>
>> requires-python = '>=2.7,!=3.0,!=3.1,!=3.2,!=3.3'
>>
>> Of course, I'd like to write this like:
>>
>> requires-python = '(>=2.7 and <3) or >= 3.4'
>>
>> I understand that OR clauses aren't supported under any syntax
>> currently, but as PEPs 566 and 508 are still open/active, wouldn't it be
>> reasonable to support something like this explicitly?
>>
>> It seems like wanting to support 2.7 and some versions of Python 3 (but
>> not all) is a fairly common need.
>
> What you're actually asking for is for the >= operator to be limited to a
> specified major version.

We actually have the ~= operator that's basically that-- not sure if
it's allowed in requires-python. But that's not sufficient. You also
need an "or" primitive if you want to express "~= 2.7 or ~= 3.4".
Right now all you could write is "~= 2.7 and ~= 3.4", which is the
null set :-).

-n

-- 
Nathaniel J. Smith -- https://vorpus.org

From vano at mail.mipt.ru  Wed Dec 13 22:27:14 2017
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Thu, 14 Dec 2017 06:27:14 +0300
Subject: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses
In-Reply-To: <CAPJVwB=1gX2KiiYRsPnxF31YrSphBzHV+1yksTsKpK02AEstCA@mail.gmail.com>
References: <p0sfv1$5c2$1@blaine.gmane.org>
 <7d4bced7-355d-1a3c-9fb1-813da5d01078@mail.mipt.ru>
 <CAPJVwB=1gX2KiiYRsPnxF31YrSphBzHV+1yksTsKpK02AEstCA@mail.gmail.com>
Message-ID: <6fd90698-5596-490e-26f0-a4015d4a10c7@mail.mipt.ru>



On 14.12.2017 5:25, Nathaniel Smith wrote:
> On Wed, Dec 13, 2017 at 6:11 PM, Ivan Pozdeev via Distutils-SIG
> <distutils-sig at python.org> wrote:
>>
>> On 14.12.2017 3:17, Barry Warsaw wrote:
>>> I'm about to release a new version of importlib_resources, so I want to
>>> get my flit.ini's require-python clause right.  We support Python 2.7,
>>> and 3.4 and beyond.  This makes me sad:
>>>
>>> requires-python = '>=2.7,!=3.0,!=3.1,!=3.2,!=3.3'
>>>
>>> Of course, I'd like to write this like:
>>>
>>> requires-python = '(>=2.7 and <3) or >= 3.4'
>>>
>>> I understand that OR clauses aren't supported under any syntax
>>> currently, but as PEPs 566 and 508 are still open/active, wouldn't it be
>>> reasonable to support something like this explicitly?
>>>
>>> It seems like wanting to support 2.7 and some versions of Python 3 (but
>>> not all) is a fairly common need.
>> What you're actually asking for is for the >= operator to be limited to a
>> specified major version.
> We actually have the ~= operator that's basically that-- not sure if
> it's allowed in requires-python. But that's not sufficient. You also
> need an "or" primitive if you want to express "~= 2.7 or ~= 3.4".
> Right now all you could write is "~= 2.7 and ~= 3.4", which is the
> null set :-).
If my logic algebra memory serves me right, `or' can be changed to `and' 
and vice versa by lowering or raising a negation line:

~= 2.7 or ~= 3.4 <=> !!(~= 2.7 or ~= 3.4) <=> !(!~=2.7 and !~=3.4)

But you need superposition (the brackets) for that.

-- 
Regards,
Ivan


From vano at mail.mipt.ru  Thu Dec 14 02:51:09 2017
From: vano at mail.mipt.ru (Ivan Pozdeev)
Date: Thu, 14 Dec 2017 10:51:09 +0300
Subject: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses
In-Reply-To: <CAPJVwB=1gX2KiiYRsPnxF31YrSphBzHV+1yksTsKpK02AEstCA@mail.gmail.com>
References: <p0sfv1$5c2$1@blaine.gmane.org>
 <7d4bced7-355d-1a3c-9fb1-813da5d01078@mail.mipt.ru>
 <CAPJVwB=1gX2KiiYRsPnxF31YrSphBzHV+1yksTsKpK02AEstCA@mail.gmail.com>
Message-ID: <93b39263-1bb2-f69c-fcd2-4d9b12fe97d0@mail.mipt.ru>



On 14.12.2017 5:25, Nathaniel Smith wrote:
> On Wed, Dec 13, 2017 at 6:11 PM, Ivan Pozdeev via Distutils-SIG
> <distutils-sig at python.org> wrote:
>>
>> On 14.12.2017 3:17, Barry Warsaw wrote:
>>> I'm about to release a new version of importlib_resources, so I want to
>>> get my flit.ini's require-python clause right.  We support Python 2.7,
>>> and 3.4 and beyond.  This makes me sad:
>>>
>>> requires-python = '>=2.7,!=3.0,!=3.1,!=3.2,!=3.3'
>>>
>>> Of course, I'd like to write this like:
>>>
>>> requires-python = '(>=2.7 and <3) or >= 3.4'
>>>
>>> I understand that OR clauses aren't supported under any syntax
>>> currently, but as PEPs 566 and 508 are still open/active, wouldn't it be
>>> reasonable to support something like this explicitly?
>>>
>>> It seems like wanting to support 2.7 and some versions of Python 3 (but
>>> not all) is a fairly common need.
>> What you're actually asking for is for the >= operator to be limited to a
>> specified major version.
> We actually have the ~= operator that's basically that-- not sure if
> it's allowed in requires-python. But that's not sufficient. You also
> need an "or" primitive if you want to express "~= 2.7 or ~= 3.4".
> Right now all you could write is "~= 2.7 and ~= 3.4", which is the
> null set :-).
With the aforementioned semantic versioning, a "natural" version 
specifier would be:

* a disjuction of major versions (probably a range),
* with each one of them possibly accompanied by a conjuction of minor 
versions.

So, yes, for this, an `or' and superposition (arbitrary or otherwise) 
are absolute requirements.

-- 
Regards,
Ivan


From chris.barker at noaa.gov  Thu Dec 14 12:08:07 2017
From: chris.barker at noaa.gov (Chris Barker - NOAA Federal)
Date: Thu, 14 Dec 2017 09:08:07 -0800
Subject: [Distutils] Or in version spec...
Message-ID: <-3572090639694368999@unknownmsgid>

Sorry to lose the thread ? lousy iPhone mail app...

Conda supports or in its meta.yaml format:

https://conda.io/docs/user-guide/tasks/build-packages/package-spec.html#build-version-spec

Maybe look to that for prior art?

And it would be mildly less confusing to have consistency between the
systems.

-Chris


Sent from my iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171214/cc06d8d6/attachment.html>

From njs at pobox.com  Thu Dec 14 18:20:43 2017
From: njs at pobox.com (Nathaniel Smith)
Date: Thu, 14 Dec 2017 15:20:43 -0800
Subject: [Distutils] Or in version spec...
In-Reply-To: <-3572090639694368999@unknownmsgid>
References: <-3572090639694368999@unknownmsgid>
Message-ID: <CAPJVwBmFK5B5p+ZfdR=oanwMh98Ezvp7x+du+gkc+aKSW-KqSQ@mail.gmail.com>

PEP 508 already allows parenthesized expressions with 'and' and 'or' for
environment markers, so that's probably the most relevant prior art. I
doubt '|' will be added at this point.

On Dec 14, 2017 09:08, "Chris Barker - NOAA Federal" <chris.barker at noaa.gov>
wrote:

>
> Sorry to lose the thread ? lousy iPhone mail app...
>
> Conda supports or in its meta.yaml format:
>
> https://conda.io/docs/user-guide/tasks/build-packages/
> package-spec.html#build-version-spec
>
> Maybe look to that for prior art?
>
> And it would be mildly less confusing to have consistency between the
> systems.
>
> -Chris
>
>
> Sent from my iPhone
>
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171214/89d34415/attachment.html>

From ncoghlan at gmail.com  Sat Dec 16 04:54:11 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sat, 16 Dec 2017 19:54:11 +1000
Subject: [Distutils] PEP 345, 566, 508 version specifiers and OR clauses
In-Reply-To: <CADiSq7cWyywxE7vhjebHa-azWeAaqNb_JuV-Jy655AxFSxDWhg@mail.gmail.com>
References: <p0sfv1$5c2$1@blaine.gmane.org>
 <0F1FEED6-A0F9-477B-B459-BDBE5BE62C50@stufft.io>
 <CADiSq7c9AvwpGd8xerbkBSxj72TmYifxki95J6Hg5Bjrie4qQg@mail.gmail.com>
 <CADiSq7cWyywxE7vhjebHa-azWeAaqNb_JuV-Jy655AxFSxDWhg@mail.gmail.com>
Message-ID: <CADiSq7eW_SXZgSuCYU-gvfzxJpsa5rrkjLGw6Q_sUUJtQPPrjQ@mail.gmail.com>

On 14 Dec. 2017 1:55 pm, "Donald Stufft" <donald at stufft.io> wrote:

Overall I?m +1, not sure if it would be a new PEP or an amendment to the
current PEPs but I think it?s a good idea.


It would be a new PEP bumping the metadata version to 1.4 (that will be
less tedious than it used to be though, since it will only have to cover
the enhancement, not duplicate all the old field descriptions).

Somwehat related though, we should probably have a summary table in PyPUG
mapping metadata versions to minimum required tooling versions & their
respective release dates. That way folks can make informed decisions about
their installability choices before deciding which version to use in their
published metadata.

Cheers,
Nick.



_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG at python.org
https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171216/966f1742/attachment.html>

From tesrin at gmail.com  Tue Dec 19 00:14:07 2017
From: tesrin at gmail.com (Jimmy Jia)
Date: Tue, 19 Dec 2017 05:14:07 +0000
Subject: [Distutils] Policy for deleting packages, releases,
 and artifacts
In-Reply-To: <CALFTs=c2u7SW4vxRnQts4Lc-3HdBZQRHS6U5pqFGH_w6sS5w5w@mail.gmail.com>
References: <CALFTs=c2u7SW4vxRnQts4Lc-3HdBZQRHS6U5pqFGH_w6sS5w5w@mail.gmail.com>
Message-ID: <CALFTs=c-gK6KiLwOWNP3vfHw-t5GbOn+RvyCLH=NtM1R1O8tNA@mail.gmail.com>

Hi,

Just following up on this proposal. I really do think it would be
beneficial to have limits on package deletion.

Thanks,
Jimmy Jia

On Wed, Nov 29, 2017 at 10:50 PM Jimmy Jia <tesrin at gmail.com> wrote:

> Hi everyone,
>
> This is moved over from
> https://github.com/pypa/packaging-problems/issues/112.
>
> Currently, PyPI has no limitations around deleting packages, releases,
> or artifacts. This can be problematic for users, as user builds can
> break in an unsolicited manner if a dependency is removed from PyPI.
>
> In the Node ecosystem, a similar lack of limitations there caused
> significant problems about a year and a half ago, when a widely-used
> package was deleted following a dispute:
> http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm,
> http://blog.npmjs.org/post/141905368000/changes-to-npms-unpublish-policy.
> At the time, the scope of the impact was characterized as "breaking
> the world".
>
> To resolve this, npm adopted a policy where package deletions (there's
> no distinction between a release and an artifact there) could only be
> done for the first 24 hours after a release was published. Deletions
> after the 24 hour mark require contacting npm support, and are
> contingent on the absence of dependents for the deleted release.
>
> Of course, npm is a venture-backed for-profit enterprise that has a
> paid support team ? that's not the case here, so the "support" half of
> the solution above doesn't make sense here. However, as a starting
> point, it might still be a good idea to restrict package deletion
> after that 24-hour window.
>
> At least, in the examples given in the links above, the deletion of
> old packages is strictly a nice-to-have for the package maintainers,
> balanced against potentially breaking impacts for users.
>
> Thanks in advance for any feedback.
>
> Thanks,
> Jimmy Jia
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171219/38b3f572/attachment.html>

From donald at stufft.io  Tue Dec 19 14:43:41 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 19 Dec 2017 14:43:41 -0500
Subject: [Distutils] Immutability of Release Metadata in Warehouse
Message-ID: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>

For those who are not aware, legacy PyPI would allow you to run ``twine register`` on a release that had already been created in order to modify the metadata that PyPI had recorded for that release (keyed by version number). This wasn?t a super widely used feature, but it?s primary use case was when folks would mistakenly release a project that had a broken description that wouldn?t correctly render on PyPI. With the move from the legacy PyPI code base to Warehouse for handling uploads, this feature had been somewhat inadvertently lost.

This issue was raised in https://github.com/pypa/warehouse/issues/2170 <https://github.com/pypa/warehouse/issues/2170>. This email is provide notice that after thinking about this issue for awhile, we?re *not* going to restore the ability to modify the metadata associated with a release after it has been uploaded.The eventual goal is that it should be ideally possible to treat the files that are on PyPI as the source of truth for all metadata, and that the data stored in the database is simply an optimization for accessing and presenting that data on PyPI. Obviously if we allow modifications to the metadata as stored in the PyPI database, that would allow this metadata to ?drift? from what is actually stored in the files, which would prevent that goal from being realized.

It is true that even with this change, there is not a guarantee that the metadata in the database does not match what is in the file(s) that have been uploaded to PyPI, even going into the future. Thus the decision to not restore this feature is not the only step on the way to being able to assert this guarantee, but it is *one* of them.

The most common reason for wanting to modify any metadata after the fact is to fix typos etc that made it into the description prior to publication. It is our opinion that the best way to handle these is to either cut a new release (it can be a post release if that?s all that has changed) or to validate the description field prior to publication (which can currently be done using readme_renderer or restview). Longer term we also plan to introduce the ability to ?stage? releases so that releases and files can be uploaded to a temporary location within Warehouse, and visible with a special URL to allow people to manually validate the actual bits that were uploaded before pushing a ?finalize? or ?publish? button that would flip it from being a mutable, hidden release to an immutable, publicly viewable release.

If folks have other use cases where they?ve used the ability to modify release metadata after it had been released that they feel is an important enough use case that it needs to be supported in some way, please let us know either in this thread or by opening an issue on https://github.com/pypa/warehouse <https://github.com/pypa/warehouse> so we can figure out if it?s something we want to support, if one of the other mechanisms we?re planning on adding will support it, or if there is some new mechanism we can add that can support it better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171219/8aac2d40/attachment.html>

From alex.gronholm at nextday.fi  Tue Dec 19 14:51:46 2017
From: alex.gronholm at nextday.fi (=?UTF-8?Q?Alex_Gr=c3=b6nholm?=)
Date: Tue, 19 Dec 2017 21:51:46 +0200
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
Message-ID: <a03c2e73-6ace-7052-3ba9-9fa5b8824cb5@nextday.fi>

Couldn't Warehouse validate the description, and reject the upload (with 
an appropriate message) if it doesn't pass? This at least would 
eliminate those ugly project pages that failed to render...there are a 
lot of them on PyPI.


Donald Stufft kirjoitti 19.12.2017 klo 21:43:
> For those who are not aware, legacy PyPI would allow you to run 
> ``twine register`` on a release that had already been created in order 
> to modify the metadata that PyPI had recorded for that release (keyed 
> by version number). This wasn?t a super widely used feature, but it?s 
> primary use case was when folks would mistakenly release a project 
> that had a broken description that wouldn?t correctly render on PyPI. 
> With the move from the legacy PyPI code base to Warehouse for handling 
> uploads, this feature had been somewhat inadvertently lost.
>
> This issue was raised in 
> https://github.com/pypa/warehouse/issues/2170.?This email is provide 
> notice that after thinking about this issue for awhile, we?re *not* 
> going to restore the ability to modify the metadata associated with a 
> release after it has been uploaded.The eventual goal is that it should 
> be ideally possible to treat the files that are on PyPI as the source 
> of truth for all metadata, and that the data stored in the database is 
> simply an optimization for accessing and presenting that data on PyPI. 
> Obviously if we allow modifications to the metadata as stored in the 
> PyPI database, that would allow this metadata to ?drift? from what is 
> actually stored in the files, which would prevent that goal from being 
> realized.
>
> It is true that even with this change, there is not a guarantee that 
> the metadata in the database does not match what is in the file(s) 
> that have been uploaded to PyPI, even going into the future. Thus the 
> decision to not restore this feature is not the only step on the way 
> to being able to assert this guarantee, but it is *one* of them.
>
> The most common reason for wanting to modify any metadata after the 
> fact is to fix typos etc that made it into the description prior to 
> publication. It is our opinion that the best way to handle these is to 
> either cut a new release (it can be a post release if that?s all that 
> has changed) or to validate the description field prior to publication 
> (which can currently be done using readme_renderer or restview). 
> Longer term we also plan to introduce the ability to ?stage? releases 
> so that releases and files can be uploaded to a temporary location 
> within Warehouse, and visible with a special URL to allow people to 
> manually validate the actual bits that were uploaded before pushing a 
> ?finalize? or ?publish? button that would flip it from being a 
> mutable, hidden release to an immutable, publicly viewable release.
>
> If folks have other use cases where they?ve used the ability to modify 
> release metadata after it had been released that they feel is an 
> important enough use case that it needs to be supported in some way, 
> please let us know either in this thread or by opening an issue on 
> https://github.com/pypa/warehouse?so we can figure out if it?s 
> something we want to support, if one of the other mechanisms we?re 
> planning on adding will support it, or if there is some new mechanism 
> we can add that can support it better.
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171219/a9989741/attachment.html>

From donald at stufft.io  Tue Dec 19 14:58:22 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 19 Dec 2017 14:58:22 -0500
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <a03c2e73-6ace-7052-3ba9-9fa5b8824cb5@nextday.fi>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
 <a03c2e73-6ace-7052-3ba9-9fa5b8824cb5@nextday.fi>
Message-ID: <1E65EAFC-38CD-49AF-B79D-E4A09C1C1691@stufft.io>


> On Dec 19, 2017, at 2:51 PM, Alex Gr?nholm <alex.gronholm at nextday.fi> wrote:
> 
> Couldn't Warehouse validate the description, and reject the upload (with an appropriate message) if it doesn't pass? This at least would eliminate those ugly project pages that failed to render...there are a lot of them on PyPI.

I forgot to mention that!

So currently the answer is No, because some projects are legitimately not attempting to use rst descriptions and we have no way to know if a project wants a rst description or a plaintext description besides just attempting to render it (which unfortunately also means that projects who want plaintext but which accidentally have something that is valid rst will get rst forced on them).

However! There is a desire to enable Markdown support for PyPI, and as part of that a new metadata field is being added that just indicates what format the description is in (rst, markdown, or plaintext is the supported ones once that field gets added). Once we get that field added and plumbed through, then we?ll have a mechanism by which we can determine if the field is supposed to render correctly, and the plan is to start rejecting uploads that include that field (the behavior if that field isn?t included would be the current behavior) where the description does not correctly render with the selected technology.

So effectively, not right now, but at some point yes, but it?ll be opt-in by adding a new bit of metadata to your project.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171219/1b60c864/attachment-0001.html>

From sh at changeset.nyc  Tue Dec 19 15:02:27 2017
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Tue, 19 Dec 2017 15:02:27 -0500
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <6f4936aa-6e9a-0fb3-c25a-f316a8dca5fa@changeset.nyc>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
 <a03c2e73-6ace-7052-3ba9-9fa5b8824cb5@nextday.fi>
 <1E65EAFC-38CD-49AF-B79D-E4A09C1C1691@stufft.io>
 <6f4936aa-6e9a-0fb3-c25a-f316a8dca5fa@changeset.nyc>
Message-ID: <971f7607-c107-c285-7d62-be0908f44378@changeset.nyc>

On 12/19/2017 03:00 PM, Sumana Harihareswara wrote:

> * supporting Markdown https://github.com/pypa/warehouse/issues/2206

Whoops: https://github.com/pypa/warehouse/issues/869 is the right link.

-- 
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc

From sh at changeset.nyc  Tue Dec 19 15:00:55 2017
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Tue, 19 Dec 2017 15:00:55 -0500
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <1E65EAFC-38CD-49AF-B79D-E4A09C1C1691@stufft.io>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
 <a03c2e73-6ace-7052-3ba9-9fa5b8824cb5@nextday.fi>
 <1E65EAFC-38CD-49AF-B79D-E4A09C1C1691@stufft.io>
Message-ID: <6f4936aa-6e9a-0fb3-c25a-f316a8dca5fa@changeset.nyc>

On 12/19/2017 02:58 PM, Donald Stufft wrote:
> 
>> On Dec 19, 2017, at 2:51 PM, Alex Gr?nholm <alex.gronholm at nextday.fi> wrote:
>>
>> Couldn't Warehouse validate the description, and reject the upload (with an appropriate message) if it doesn't pass? This at least would eliminate those ugly project pages that failed to render...there are a lot of them on PyPI.
> 
> I forgot to mention that!
> 
> So currently the answer is No, because some projects are legitimately not attempting to use rst descriptions and we have no way to know if a project wants a rst description or a plaintext description besides just attempting to render it (which unfortunately also means that projects who want plaintext but which accidentally have something that is valid rst will get rst forced on them).
> 
> However! There is a desire to enable Markdown support for PyPI, and as part of that a new metadata field is being added that just indicates what format the description is in (rst, markdown, or plaintext is the supported ones once that field gets added). Once we get that field added and plumbed through, then we?ll have a mechanism by which we can determine if the field is supposed to render correctly, and the plan is to start rejecting uploads that include that field (the behavior if that field isn?t included would be the current behavior) where the description does not correctly render with the selected technology.
> 
> So effectively, not right now, but at some point yes, but it?ll be opt-in by adding a new bit of metadata to your project.

GitHub issue links for those who want to track them:

* staged releases https://github.com/pypa/warehouse/issues/726
* supporting Markdown https://github.com/pypa/warehouse/issues/2206
* advising packagers to run `python setup.py check -r -s`
https://github.com/pypa/python-packaging-user-guide/issues/210

-- 
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc

From sh at changeset.nyc  Tue Dec 19 15:08:24 2017
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Tue, 19 Dec 2017 15:08:24 -0500
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
Message-ID: <a18477ea-9da5-db39-1229-1d15fbaedc9a@changeset.nyc>

For those who want to track the relevant GitHub issues:

* supporting Markdown https://github.com/pypa/warehouse/issues/869
* staged releases https://github.com/pypa/warehouse/issues/726
* advising packagers to run `python setup.py check -r -s`
https://github.com/pypa/python-packaging-user-guide/issues/210

-- 
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc

From bussonniermatthias at gmail.com  Tue Dec 19 16:10:12 2017
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Tue, 19 Dec 2017 22:10:12 +0100
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <CANJQusUMUs2JyzJr4Hcc+rf8yNsneebX9mBW7GYaB-HqDpSwDg@mail.gmail.com>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
 <a18477ea-9da5-db39-1229-1d15fbaedc9a@changeset.nyc>
 <CANJQusXdBEBUMkPpZhLg1pMJLxkTm3+7xdC+E-R45ex7UFwvPA@mail.gmail.com>
 <CANJQusUMUs2JyzJr4Hcc+rf8yNsneebX9mBW7GYaB-HqDpSwDg@mail.gmail.com>
Message-ID: <CANJQusVVuh3R-eWQfuBYziD3umczzn2-USPrz2+3gBOyU8admA@mail.gmail.com>

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 2 compatible download it and crash.

I'm going to assume with time more packages will be affected even with
minor version of Python.

-- 
M


On Dec 19, 2017 21:17, "Sumana Harihareswara" <sh at changeset.nyc> wrote:

For those who want to track the relevant GitHub issues:

* supporting Markdown https://github.com/pypa/warehouse/issues/869
* staged releases https://github.com/pypa/warehouse/issues/726
* advising packagers to run `python setup.py check -r -s`
https://github.com/pypa/python-packaging-user-guide/issues/210

--
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG at python.org
https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171219/1ed0dcd6/attachment.html>

From thomas at kluyver.me.uk  Tue Dec 19 16:21:30 2017
From: thomas at kluyver.me.uk (Thomas Kluyver)
Date: Tue, 19 Dec 2017 21:21:30 +0000
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <CANJQusVVuh3R-eWQfuBYziD3umczzn2-USPrz2+3gBOyU8admA@mail.gmail.com>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
 <a18477ea-9da5-db39-1229-1d15fbaedc9a@changeset.nyc>
 <CANJQusXdBEBUMkPpZhLg1pMJLxkTm3+7xdC+E-R45ex7UFwvPA@mail.gmail.com>
 <CANJQusUMUs2JyzJr4Hcc+rf8yNsneebX9mBW7GYaB-HqDpSwDg@mail.gmail.com>
 <CANJQusVVuh3R-eWQfuBYziD3umczzn2-USPrz2+3gBOyU8admA@mail.gmail.com>
Message-ID: <1513718490.3997865.1210488824.3F9D8723@webmail.messagingengine.com>

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 2 compatible download it and crash.
Something similar happened to pytest - version 3.3 dropped support for
Python 3.3 (the numbering is a coincidence,  AFAIK). The requires-python
metadata was set in the package, but the package was published via a
devpi server, which didn't preserve that metadata correctly to send to
PyPI. So now 'pip install pytest' on Python 3.3 downloads the new
version and fails, rather than downloading an older, compatible version.
The only way the project can fix this is to delete the releases with
incorrect metadata.
I support the larger goal of making metadata on PyPI match the metadata
in the package, however.
Thomas


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171219/8f5072a8/attachment-0001.html>

From bussonniermatthias at gmail.com  Tue Dec 19 16:30:55 2017
From: bussonniermatthias at gmail.com (Matthias Bussonnier)
Date: Tue, 19 Dec 2017 22:30:55 +0100
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <1513718490.3997865.1210488824.3F9D8723@webmail.messagingengine.com>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
 <a18477ea-9da5-db39-1229-1d15fbaedc9a@changeset.nyc>
 <CANJQusXdBEBUMkPpZhLg1pMJLxkTm3+7xdC+E-R45ex7UFwvPA@mail.gmail.com>
 <CANJQusUMUs2JyzJr4Hcc+rf8yNsneebX9mBW7GYaB-HqDpSwDg@mail.gmail.com>
 <CANJQusVVuh3R-eWQfuBYziD3umczzn2-USPrz2+3gBOyU8admA@mail.gmail.com>
 <1513718490.3997865.1210488824.3F9D8723@webmail.messagingengine.com>
Message-ID: <CANJQusX=7RNzxZW0u49sax=1bu6jWBkTRYqCyNc1L6=4O0J=JA@mail.gmail.com>

I support the goal of making metadata match files as well. One alternative
is have the ability to "yank" a package. Make it still available, but
installable only when pinned explicitly. I believe that's what Rust does.
-- 
M

On Dec 19, 2017 22:21, "Thomas Kluyver" <thomas at kluyver.me.uk> wrote:

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 2 compatible download it and crash.


Something similar happened to pytest - version 3.3 dropped support for
Python 3.3 (the numbering is a coincidence,  AFAIK). The requires-python
metadata was set in the package, but the package was published via a devpi
server, which didn't preserve that metadata correctly to send to PyPI. So
now 'pip install pytest' on Python 3.3 downloads the new version and fails,
rather than downloading an older, compatible version. The only way the
project can fix this is to delete the releases with incorrect metadata.

I support the larger goal of making metadata on PyPI match the metadata in
the package, however.

Thomas



_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG at python.org
https://mail.python.org/mailman/listinfo/distutils-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171219/fd0b6f51/attachment.html>

From donald at stufft.io  Tue Dec 19 16:46:12 2017
From: donald at stufft.io (Donald Stufft)
Date: Tue, 19 Dec 2017 16:46:12 -0500
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <CANJQusX=7RNzxZW0u49sax=1bu6jWBkTRYqCyNc1L6=4O0J=JA@mail.gmail.com>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
 <a18477ea-9da5-db39-1229-1d15fbaedc9a@changeset.nyc>
 <CANJQusXdBEBUMkPpZhLg1pMJLxkTm3+7xdC+E-R45ex7UFwvPA@mail.gmail.com>
 <CANJQusUMUs2JyzJr4Hcc+rf8yNsneebX9mBW7GYaB-HqDpSwDg@mail.gmail.com>
 <CANJQusVVuh3R-eWQfuBYziD3umczzn2-USPrz2+3gBOyU8admA@mail.gmail.com>
 <1513718490.3997865.1210488824.3F9D8723@webmail.messagingengine.com>
 <CANJQusX=7RNzxZW0u49sax=1bu6jWBkTRYqCyNc1L6=4O0J=JA@mail.gmail.com>
Message-ID: <FB03AEA9-77C5-4463-8D02-02EB37F42397@stufft.io>


> On Dec 19, 2017, at 4:30 PM, Matthias Bussonnier <bussonniermatthias at gmail.com> wrote:
> 
> One alternative is have the ability to "yank" a package. Make it still available, but installable only when pinned explicitly. I believe that's what Rust does. 

The ability to yank a package is something I?d love to introduce, unfortunately it will require changes to the API that tools like pip use, because PyPI does not currently have any idea why you?re asking for a list of the releases, just that you?re asking for one. We?d also want to do it in a way that doesn?t introduce unnecessary overhead in terms of HTTP requests or caching (for instance, previously pip would look up /simple/foo/2.0/ if you did ``pip install foo==2.0`` but we removed that because in 99% of cases it wasn?t going to be more helpful than just requesting /simple/foo/ and it made it harder to cache our pages I Fastly for everything).

One possible solution is to simply add a ``data-yanked=true`` field on /simple/foo/. That would mean that much like requires-python you?d need to have a new enough pip to support yanked packages properly but it wouldn?t destroy our cacheability like the old method did. This wouldn?t require any real changes to any of the mirroring tooling and static mirrors would still be totally feature complete.

Another possible option is to just exclude the yanked listing by default, but have something like ?yanked=true added to the URL which would then include *all* the yanked releases. This is ?safe? to do in the case of ==, because adding extraneous yanked releases isn?t going to matter, since the == will only allow it to install one of them anyways. It bloats our cache a bit (two versions of the /simple/<foo>/ url for each project instead of 1) but it doesn?t completely destroy it like the /simple/foo/<version>/ scheme did. This option would mean that older versions of tools simply wouldn?t see the yanked versions ever, even with ==. It also would probably preclude the ability to have a fully static mirror, since you?d need something to handle the ?yanked=true handling (although we could maybe get around that by using something like /simple/_yanked/foo/ or something).

There are possibly other ideas to handle this that I?m not thinking of offhand, but I think fundamentally the question will come down to whether we want older versions of the tooling to see yanked packages by default or not.

Ultimately this is probably a big enough feature that it would deserve a PEP to flesh out the various options and to figure out which path we go down. Unfortunately I don?t currently have time to handle that, but would gladly participate in such a discussion if someone were to lead it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171219/b592cb81/attachment.html>

From suchitraraniojha at gmail.com  Tue Dec 19 22:30:52 2017
From: suchitraraniojha at gmail.com (Suchitrarani Ojha)
Date: Wed, 20 Dec 2017 09:00:52 +0530
Subject: [Distutils] (no subject)
Message-ID: <CAJ=NFL6Kf2gUO4SuFdJUv4aheUrjV-dv+9dyMKE1N8vHJ47xdw@mail.gmail.com>

Sir,
I have recently downloaded python 3.6 version and I am  very new to
python.I tried to  open excel files in python  using openpyxl but its
shows"Module not found error".So I tried to install it using pip install
openpyxl and it was showing Syntax error:'Invalid syntax'.Can you help me
in resolving the issue.


Regards
suchitra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171220/be48a60c/attachment.html>

From p.f.moore at gmail.com  Wed Dec 20 10:38:03 2017
From: p.f.moore at gmail.com (Paul Moore)
Date: Wed, 20 Dec 2017 15:38:03 +0000
Subject: [Distutils] (no subject)
In-Reply-To: <CAJ=NFL6Kf2gUO4SuFdJUv4aheUrjV-dv+9dyMKE1N8vHJ47xdw@mail.gmail.com>
References: <CAJ=NFL6Kf2gUO4SuFdJUv4aheUrjV-dv+9dyMKE1N8vHJ47xdw@mail.gmail.com>
Message-ID: <CACac1F8C=xdPPuMeWZTrOJn9QsZi1T5fm4dSbzzL2H1ZcHHQQA@mail.gmail.com>

The likelihood is, from your description, that you are typing the "pip
install openpyxl" command at the Python prompt, rather than the
Windows command line. Do you understand what the "command line" is on
your computer? If you're on Windows, it's what you get when you run
the "cmd" program (which shows in the start menu as "Command Prompt".
You may need to set your PATH environment variable to get access to
the pip command, but if that's something you are unsure about, "py -m
pip install openpyxl" (at the command prompt) should do what you want.

For a more detailed explanation, you should try
https://packaging.python.org/tutorials/installing-packages/ although
it does assume a basic familiarity with the command line, so you may
also need to google for some basic tutorials on how to use the command
line, to support the information in that link.

Hope this helps, and welcome to the Python community!

Paul

On 20 December 2017 at 03:30, Suchitrarani Ojha
<suchitraraniojha at gmail.com> wrote:
> Sir,
> I have recently downloaded python 3.6 version and I am  very new to python.I
> tried to  open excel files in python  using openpyxl but its shows"Module
> not found error".So I tried to install it using pip install openpyxl and it
> was showing Syntax error:'Invalid syntax'.Can you help me in resolving the
> issue.
>
>
> Regards
> suchitra
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>

From sh at changeset.nyc  Wed Dec 20 17:34:21 2017
From: sh at changeset.nyc (Sumana Harihareswara)
Date: Wed, 20 Dec 2017 17:34:21 -0500
Subject: [Distutils] Warehouse update: highest priority tasks
In-Reply-To: <d10c3698-2dd9-641b-f4ee-a233b4476e71@changeset.nyc>
References: <d10c3698-2dd9-641b-f4ee-a233b4476e71@changeset.nyc>
Message-ID: <a6a8a868-111f-823f-bce5-4091543c7e4f@changeset.nyc>

Cross-posting from pypa-dev
https://groups.google.com/forum/#!topic/pypa-dev/2hulwNQFhRk . I'm
realizing that pypa-dev might be a better place to send updates like
this than distutils-sig and would appreciate feedback on that question
(probably off-list is better).
-Sumana Harihareswara

-------- Forwarded Message --------
Subject: Warehouse update: highest priority tasks
Date: Tue, 19 Dec 2017 18:59:01 -0500
From: Sumana Harihareswara <sh at changeset.nyc>
To: pypa-dev at googlegroups.com

Today the Warehouse project team met to discuss what to deliver first,
in the Maintainer MVP milestone[0] (full notes on the Python wiki[1]).
The point of this first milestone is to give package maintainers a solid
chance to try out Warehouse and report critical bugs early.

We'll include several features to let users change and update your
accounts & project files:
* Enable pages to delete, hide, unhide a project/release/file[2]
* Enable users to modify their own account[3]
* UI for adding maintainers[4]
* Implement "reset lost password" feature[5]

Due to changes in hosting documentation on pythonhosted, we will
implement a button for users to delete or redirect the documentation
they uploaded.[6]

We'll make and maintain a roadmap and publicize it on pypi.org, then
move it to our GitHub repo when work probably slows down after the
launch.[7]

We've slotted in some additional issues, and we made some decisions
about release metadata immutability[8] and a couple other issues you?ll
hear more about on distutils-sig in the next couple days.

So now that we've made this first pass and are fairly confident what?s
left between us and this first milestone, we're figuring out how long
it'll be till we can deliver that. Laura Hampton and I will keep you
posted. And we welcome help in GitHub[9] and feedback on GitHub issues
or here on the list!

-Sumana Harihareswara

[0] https://github.com/pypa/warehouse/milestone/8
[1] https://wiki.python.org/psf/PackagingWG/2017-12-19-Warehouse
[2] https://github.com/pypa/warehouse/issues/424
[3] https://github.com/pypa/warehouse/issues/423
[4] https://github.com/pypa/warehouse/issues/956
[5] https://github.com/pypa/warehouse/issues/1228
[6] https://github.com/pypa/warehouse/issues/582
[7] https://github.com/pypa/warehouse/issues/1322
[8]
https://mail.python.org/pipermail/distutils-sig/2017-December/031826.html
[9]
https://github.com/pypa/warehouse/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22

P.S. Thanks to Laura Hampton for help with prep, meeting-running, and
followup.
-- 
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc

From tesrin at gmail.com  Wed Dec 20 17:47:00 2017
From: tesrin at gmail.com (Jimmy Jia)
Date: Wed, 20 Dec 2017 22:47:00 +0000
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <FB03AEA9-77C5-4463-8D02-02EB37F42397@stufft.io>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
 <a18477ea-9da5-db39-1229-1d15fbaedc9a@changeset.nyc>
 <CANJQusXdBEBUMkPpZhLg1pMJLxkTm3+7xdC+E-R45ex7UFwvPA@mail.gmail.com>
 <CANJQusUMUs2JyzJr4Hcc+rf8yNsneebX9mBW7GYaB-HqDpSwDg@mail.gmail.com>
 <CANJQusVVuh3R-eWQfuBYziD3umczzn2-USPrz2+3gBOyU8admA@mail.gmail.com>
 <1513718490.3997865.1210488824.3F9D8723@webmail.messagingengine.com>
 <CANJQusX=7RNzxZW0u49sax=1bu6jWBkTRYqCyNc1L6=4O0J=JA@mail.gmail.com>
 <FB03AEA9-77C5-4463-8D02-02EB37F42397@stufft.io>
Message-ID: <CALFTs=d=Cv9a97p29nj9DQs=Ssah-M4ppRBVfGHu2ChiZ0O6_A@mail.gmail.com>

Another thing that arises with yanking is the idea of deprecating releases
or packages.

While in many cases yanking is sufficient, it's nice to have a way to
explicitly deprecate rather than yank packages that are e.g. no longer
maintained, have been renamed, or have better replacements, without
necessarily cutting a new release (as that may not inform existing users).

I've done so for my packages before by editing the package description and
replacing it with a deprecation notice.

On Tue, Dec 19, 2017 at 4:46 PM Donald Stufft <donald at stufft.io> wrote:

>
> On Dec 19, 2017, at 4:30 PM, Matthias Bussonnier <
> bussonniermatthias at gmail.com> wrote:
>
> One alternative is have the ability to "yank" a package. Make it still
> available, but installable only when pinned explicitly. I believe that's
> what Rust does.
>
>
> The ability to yank a package is something I?d love to introduce,
> unfortunately it will require changes to the API that tools like pip use,
> because PyPI does not currently have any idea why you?re asking for a list
> of the releases, just that you?re asking for one. We?d also want to do it
> in a way that doesn?t introduce unnecessary overhead in terms of HTTP
> requests or caching (for instance, previously pip would look up
> /simple/foo/2.0/ if you did ``pip install foo==2.0`` but we removed that
> because in 99% of cases it wasn?t going to be more helpful than just
> requesting /simple/foo/ and it made it harder to cache our pages I Fastly
> for everything).
>
> One possible solution is to simply add a ``data-yanked=true`` field on
> /simple/foo/. That would mean that much like requires-python you?d need to
> have a new enough pip to support yanked packages properly but it wouldn?t
> destroy our cacheability like the old method did. This wouldn?t require any
> real changes to any of the mirroring tooling and static mirrors would still
> be totally feature complete.
>
> Another possible option is to just exclude the yanked listing by default,
> but have something like ?yanked=true added to the URL which would then
> include *all* the yanked releases. This is ?safe? to do in the case of ==,
> because adding extraneous yanked releases isn?t going to matter, since the
> == will only allow it to install one of them anyways. It bloats our cache a
> bit (two versions of the /simple/<foo>/ url for each project instead of 1)
> but it doesn?t completely destroy it like the /simple/foo/<version>/ scheme
> did. This option would mean that older versions of tools simply wouldn?t
> see the yanked versions ever, even with ==. It also would probably preclude
> the ability to have a fully static mirror, since you?d need something to
> handle the ?yanked=true handling (although we could maybe get around that
> by using something like /simple/_yanked/foo/ or something).
>
> There are possibly other ideas to handle this that I?m not thinking of
> offhand, but I think fundamentally the question will come down to whether
> we want older versions of the tooling to see yanked packages by default or
> not.
>
> Ultimately this is probably a big enough feature that it would deserve a
> PEP to flesh out the various options and to figure out which path we go
> down. Unfortunately I don?t currently have time to handle that, but would
> gladly participate in such a discussion if someone were to lead it.
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171220/d994550d/attachment.html>

From u10110608 at tuks.co.za  Sat Dec 23 14:08:47 2017
From: u10110608 at tuks.co.za (Jeremiah Lethoba)
Date: Sat, 23 Dec 2017 21:08:47 +0200
Subject: [Distutils] How do add Numpy package on Python
Message-ID: <CAFfj94GqXGdOT6-8L6ZAhsF4HO3qkV4wMW=vdOr+W7yQ2Odb9g@mail.gmail.com>

Hello I installed Python on a MacBook but it does not have numpy
package. How do i add it ?

-- 
This message and attachments are subject to a disclaimer. Please refer to 
http://www.it.up.ac.za/documentation/governance/disclaimer/ for full 
details.

From ncoghlan at gmail.com  Mon Dec 25 18:18:41 2017
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 26 Dec 2017 09:18:41 +1000
Subject: [Distutils] Immutability of Release Metadata in Warehouse
In-Reply-To: <1E65EAFC-38CD-49AF-B79D-E4A09C1C1691@stufft.io>
References: <85D70439-821D-4046-B7D9-7158B38E7384@stufft.io>
 <a03c2e73-6ace-7052-3ba9-9fa5b8824cb5@nextday.fi>
 <1E65EAFC-38CD-49AF-B79D-E4A09C1C1691@stufft.io>
Message-ID: <CADiSq7dm9J=LQAtH5ANn+fCrbPEW8W_o=9R+mZutpcPQ04f+Fg@mail.gmail.com>

On 20 December 2017 at 05:58, Donald Stufft <donald at stufft.io> wrote:
> However! There is a desire to enable Markdown support for PyPI, and as part
> of that a new metadata field is being added that just indicates what format
> the description is in (rst, markdown, or plaintext is the supported ones
> once that field gets added). Once we get that field added and plumbed
> through, then we?ll have a mechanism by which we can determine if the field
> is supposed to render correctly, and the plan is to start rejecting uploads
> that include that field (the behavior if that field isn?t included would be
> the current behavior) where the description does not correctly render with
> the selected technology.

The Description-Content-Type field has been added to the spec:
https://packaging.python.org/specifications/core-metadata/#description-content-type-optional

(This was part of the motivation for Dustin's metadata 1.3 PEP, to
help make it more readily apparent that we'd added that)

So the missing step is the "plumbing through" part, such that the
publishing tools support setting it, and Warehouse supports ensuring
the description renders at upload time.

However, there's still a difference between "renders without error"
and "renders the way the developer intended", so your initial post
will still stand for those kinds of problems (as well as typo fixes,
etc).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia