[Distutils] Re: Python 3.7 binary wheels

[Nathaniel Smith]

On Tue, May 8, 2018 at 7:35 PM, Steve Dower  wrote:
> On 08May2018 2134, Nathaniel Smith wrote:
>> for 3.6 there was a last minute problem
>> with the Windows ABI that only got discovered during the rc period. But
>> if you're willing to keep an ear out for that sort of thing, go wild.
>
> I thought this was 3.5 (or maybe I've blanked out the more recent one)?

Doh, no, this is just what I get for trying to send email while
waiting for bags at the airport.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/ACTRYRTY422O3PA33NCHNFCKT7HDTWYH/

[Distutils] Re: Python 3.7 binary wheels

[Steve Dower]

On 08May2018 2134, Nathaniel Smith wrote:
> for 3.6 there was a last minute problem
> with the Windows ABI that only got discovered during the rc period. But
> if you're willing to keep an ear out for that sort of thing, go wild.

I thought this was 3.5 (or maybe I've blanked out the more recent one)?
And the only reason we discovered it is because someone started building
wheels just before release. So please start building your wheels and let
us know as soon as possible if anything seems wrong!

Thanks,
Steve
--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/SB2BKEMXQS2BD25XDUGUTATGXPTOWXSW/

[Distutils] Re: Python 3.7 binary wheels

[Nathaniel Smith]

On Tue, May 8, 2018, 20:59 Lele Gaifax  wrote:

> Hi all,
>
> Python 3.7 is steadily approaching its final release and I start wondering
>
> a) when will be the right time to start uploading 3.7 binary wheels on
> PyPI?
>

The ABI was frozen at 3.7b3 (we're currently at b4), so in theory you can
start uploading wheels any time. Of course, there's still some risk until
it's actually released – for 3.6 there was a last minute problem with the
Windows ABI that only got discovered during the rc period. But if you're
willing to keep an ear out for that sort of thing, go wild.


> b) if/when manylinux2010 happens, does that mean that I should build both
>manylinux1 and manylinux2010 variants?
>

Totally up to you. The only real differences are that RHEL/CentOS 5 users
can use manylinux1 wheels but won't be able to use manylinux2010 wheels,
and that manylinux2010 will require a newer pip. You can upload one or both
depending on what you think works best for your users.

-n
--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/3NFDHX47NDH4ZFTWHYEVMDQ6K7VX4MQZ/

[Distutils] Python 3.7 binary wheels

[Lele Gaifax]

Hi all,

Python 3.7 is steadily approaching its final release and I start wondering

a) when will be the right time to start uploading 3.7 binary wheels on PyPI?

b) if/when manylinux2010 happens, does that mean that I should build both
   manylinux1 and manylinux2010 variants?

Thank you in advance,
ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.
--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/3MHSOCGSWDWO2AEBUSZLEBBROGXTQ3E5/

[Distutils] Re: org-mode README file formats

[Leonardo Rochael Almeida]

On 8 May 2018 at 15:00, Diane Trout  wrote:

> On Tue, 2018-05-08 at 16:44 +, Brett Cannon wrote:
>
>
>
> On Mon, 7 May 2018 at 16:54 Diane Trout  wrote:
>
> Hi,
>
> I was building a package where I had a README.org file, which
> setuptools couldn't find.
>
> It listed .md as a valid format, so I was wondering if org-mode was
> sufficiently plain text to be added to the list of accepted README file
> formats?
>
>
> What's org-mode? Sounds like an Emacs thing based on what I have heard
> Emacs people say. :)
>
> If it is an Emacs thing then I would vote "no" since that's very
> editor-specific and I suspect trying to support every plaintext file format
> is never-ending.
>
>
> Well yes, it's certainly most powerful, flexible, and feature complete
> with emacs, but there is work on org-mode support in vim and sublime.
> Additionally org-mode syntax is supported by GitHub, GitLab, and pandoc.
> 
> https://en.wikipedia.org/wiki/Org-mode#Integration
>
> There's also an argument that org-mode is a good lightweight markup
> language in and of itself.
> http://karl-voit.at/2017/09/23/orgmode-as-markup-only/
> [...]
>

Maybe you can use pandoc as a `setup_depends` and convert it to an
acceptable format at build time?
--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/CKHKNTNUNEHQ6DSZ3WJVKBWNHVHOSJKU/

[Distutils] Re: proposing Python package index upload API spec (potential PEP)

[Thomas Kluyver]

I like this practice of writing specifications to better document interfaces 
that already exist. However, in this case I wonder if it would be better to 
spend the time defining a new, simpler API instead? I think we're currently in 
a position where most tools could use a new upload API relatively quickly once 
it was defined.

On Tue, May 8, 2018, at 7:09 PM, Sumana Harihareswara wrote:
> As a new Twine maintainer I've been running into questions like:
> 
> * Now that Warehouse doesn't use "register" anymore, can we deprecate it 
> from distutils, setuptools, and twine? Are any other package indexes or 
> upload tools using it? https://github.com/pypa/twine/issues/311
> * It would be nice if Twine could depend on a package index providing an 
> HTTP 201 response in response to a successful upload, and fail on 200 (a 
> response some non-package-index servers will give to an arbitrary POST 
> request).
> 
> I do not see specifications to guide me here, e.g., in the official 
> guidance on hosting one's own package index 
> https://packaging.python.org/guides/hosting-your-own-index/ . PEP 301 
> was long enough ago that it's due an update, and PEP 503 only concerns 
> browsing and download, not upload.
> 
> I suggest that I write a PEP specifying an API for uploading to a Python 
> package index. This PEP would partially supersede PEP 301 and would 
> document the Warehouse reference implementation. I would write it in 
> collaboration with the Warehouse maintainers who will develop the 
> reference implementation per pypa/warehouse/issues/284 and maybe add a 
> header referring to compliance with this new standard. And I would 
> consult with the maintainers of packaging and distribution tools such as 
> zest.releaser, flit, poetry, devpi, pypiserver, etc.
> 
> Per Nick Coghlan's formulation, my specific goal here would be close to:
> 
> > Documenting what the current upload API between twine & warehouse actually 
> > is, similar to the way PEP 503 focused on describing the status quo, 
> > without making any changes to it. That way, other servers (like devpi) and 
> > other upload clients have the info they need to help ensure 
> > interoperability.
> 
> Since Warehouse is trying to redo its various APIs in the next several 
> months, I think it might be more useful to document and work with the 
> new upload API, but I'm open to feedback on this.
> 
> After a little conversation here on distutils-sig, I believe my steps would 
> be:
> 
> 1. start a very early PEP draft with lots of To Be Determined blanks, 
> submit as a PR to the python/peps repo, and share it with distutils-sig
> 2. ping maintainers of related tools
> 3. discuss with others at the packaging sprints 
> https://wiki.python.org/psf/PackagingSprints next week
> 4. revise and get consensus, preferably mostly on this list
> 5. finalize PEP and get PEP accepted by BDFL-Delegate
> 6. coordinate with PyPA, maintainers of `distutils`, maintainers of 
> packaging and distribution tools, and documentation maintainers to 
> implement PEP compliance
> 
> Thoughts are welcome. I originally posted this at 
> https://github.com/pypa/packaging-problems/issues/128 .
> -- 
> Sumana Harihareswara
> Changeset Consulting
> https://changeset.nyc
> --
> Distutils-SIG mailing list
> distutils-sig@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at 
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/WEPTF7Q7475UA7VVULDLIG3A445WOCLI/
--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/XZCYC7SZUJQDU3M4QSZULMRGYX3N2RH4/

[Distutils] Re: org-mode README file formats

[Thomas Kluyver]

On Tue, May 8, 2018, at 5:44 PM, Brett Cannon wrote:
> If it is an Emacs thing then I would vote "no" since that's very editor-
> specific and I suspect trying to support every plaintext file format
> is never-ending.
Currently the metadata spec defines the permitted mimetypes. Maybe we
should make this more open ended, and leave the set of useful values up
to what projects (primarily PyPI) choose to implement?
The specification could still say that any format should be a) UTF-8
text - so no README.pdf or README.doc, and b) sufficiently 'plain' that
it's readable if tools display it unrendered. The second condition is a
bit vague - I might find something readable that you don't - but it's
meant to exclude things like HTML and Latex.
I don't see any big advantage in specifying a list of allowed content
types. Even with the list we have, tools can't rely on any features of
the content except that it's UTF-8. The only real difference is whether
people who want to use something else file an issue on Warehouse or
start a thread here. :-)
Thomas
--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/QUB7AMTOKQRMRNAZ5HDL7ICIBAZLUAMB/

[Distutils] Re: Packaging/Warehouse sprint at PyCon 2018

[Sumana Harihareswara]

Reminder: it's free to attend and participate in the PyCon development sprints 
(you don't need a Talks and Events PyCon registration to come to the sprints).

If you live anywhere nearish Cleveland, even if you couldn't make it to the 
talks days, consider joining us at least for Monday May 14th, which will 
probably have the most discussion.

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

On 05/01/2018 05:29 PM, Sumana Harihareswara wrote:
> https://wiki.python.org/psf/PackagingSprints now has more info:
> 
> * we'll have at least one Open Space/Birds of a Feather session on packaging
> * folks representing Anaconda/conda-build, bandersnatch, Pipenv, GitHub,
> the Python Packaging User Guide, & more will be at the sprints
> * more things we'll work on
> 
> Happy to take suggestions on things to talk about and work on during the
> BoF and sprints!
> -Sumana
> 
> 
> On 03/13/2018 10:04 AM, Sumana Harihareswara wrote:
>> https://wiki.python.org/psf/PackagingSprints is where I've started a
>> list of our upcoming planned sprints (right now, PyCon North America and
>> EuroPython), with who's attending each and what we might work on there.
>>
>> At PyCon in Cleveland, possible work includes:
>>
>> * User testing
>> * Updating the PyPA roadmap
>> * Packaging Problems triage
>> * PyPI API keys and two-factor auth, with Luke Sneeringer & Donald Stufft
>> * Architecture for new Warehouse API URL structure
>>
>> -Sumana
>>
>> On 02/13/2018 11:22 PM, Sumana Harihareswara wrote:
>>> Reminder: this Thursday, Feb. 15th, is the last day to request financial
>>> aid to attend PyCon https://us.pycon.org/2018/financial-assistance/ and
>>> thus the sprints. If money's a reason you're assuming you can't come
>>> join us and improve Warehouse and other Python packaging/distribution
>>> tools, I hope you'll apply for financial assistance.
>>>
>>> On 01/30/2018 01:39 PM, Sumana Harihareswara wrote:
 In case you're planning your PyCon Cleveland travel: we are planning to
 hold a Warehouse/packaging sprint at PyCon (the sprints are Monday, May
 14th - Thursday, May 17th 2018).

 We welcome package maintainers, backend and frontend web developers,
 infrastructure administrators, technical writers, and testers to help us
 make the new PyPI, and the packaging ecosystem more generally, as usable
 and robust as possible. I took the liberty of updating
 https://us.pycon.org/2018/community/sprints/ to say so.

 Once we're closer to the sprints I'll work on a more detailed list of
 things we'll work on in Cleveland.

--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/DXB2UKSIDHZRFLHX4EAIRPMPQL4AEIHV/

[Distutils] Re: org-mode README file formats

[Alex Walters]

If warehouse punted to a tool like pandoc already, I would see no problem with 
adding support for everything that pandoc supported (can you imagine – 
reademe.docx?), but just skimming the requirements file, they are pulling in 
docutils and mistune, which means they have written warehouse to support rst 
and markdown, and it is not non-trivial (or less non-trivial) to support other 
markup languages.

 

Markdown won in the wider world.  Supporting that is obvious.

 

RestructuredText has inertia in the python community.  Supporting that is 
obvious.

 

Org-mode?  Asciidoc?  Txt2tags? Textile? Mediawiki?  BB Code?  Where do you 
draw the line?  I think the two languages the tooling currently support are 
sufficient for now.

 

From: Brett Cannon  
Sent: Tuesday, May 8, 2018 2:04 PM
To: Diane Trout 
Cc: distutils-sig@python.org
Subject: [Distutils] Re: org-mode README file formats

 

 

On Tue, 8 May 2018 at 11:00 Diane Trout  
> wrote:

On Tue, 2018-05-08 at 16:44 +, Brett Cannon wrote:

 

On Mon, 7 May 2018 at 16:54 Diane Trout  
> wrote:

Hi,

I was building a package where I had a README.org file, which
setuptools couldn't find.

It listed .md as a valid format, so I was wondering if org-mode was
sufficiently plain text to be added to the list of accepted README file
formats?

 

What's org-mode? Sounds like an Emacs thing based on what I have heard Emacs 
people say. :)

If it is an Emacs thing then I would vote "no" since that's very 
editor-specific and I suspect trying to support every plaintext file format is 
never-ending.

 

Well yes, it's certainly most powerful, flexible, and feature complete with 
emacs, but there is work on org-mode support in vim and sublime. Additionally 
org-mode syntax is supported by GitHub, GitLab, and pandoc.

https://en.wikipedia.org/wiki/Org-mode#Integration

 

There's also an argument that org-mode is a good lightweight markup language in 
and of itself.

http://karl-voit.at/2017/09/23/orgmode-as-markup-only/

 

Since it is breaking out of its source community I thought it at least worth 
asking about. Out of curiosity, do you have a feeling for how popular a 
lightweight markup language needs to be before it gets added to the list of 
setuptools recognized formats?

 

When you can say "has broken out" instead of "is breaking out". ;)

Basically if the majority of people at a Python conference won't know the 
format then the burden on the volunteers to support it isn't probably worth it 
IMO. But since I'm not maintaining Warehouse it isn't my call, just my opinion.

--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/D46BMY5L22WIYJXKUYBCTYGJV37RHF2O/

[Distutils] proposing Python package index upload API spec (potential PEP)

[Sumana Harihareswara]

As a new Twine maintainer I've been running into questions like:

* Now that Warehouse doesn't use "register" anymore, can we deprecate it from 
distutils, setuptools, and twine? Are any other package indexes or upload tools 
using it? https://github.com/pypa/twine/issues/311
* It would be nice if Twine could depend on a package index providing an HTTP 
201 response in response to a successful upload, and fail on 200 (a response 
some non-package-index servers will give to an arbitrary POST request).

I do not see specifications to guide me here, e.g., in the official guidance on 
hosting one's own package index 
https://packaging.python.org/guides/hosting-your-own-index/ . PEP 301 was long 
enough ago that it's due an update, and PEP 503 only concerns browsing and 
download, not upload.

I suggest that I write a PEP specifying an API for uploading to a Python 
package index. This PEP would partially supersede PEP 301 and would document 
the Warehouse reference implementation. I would write it in collaboration with 
the Warehouse maintainers who will develop the reference implementation per 
pypa/warehouse/issues/284 and maybe add a header referring to compliance with 
this new standard. And I would consult with the maintainers of packaging and 
distribution tools such as zest.releaser, flit, poetry, devpi, pypiserver, etc.

Per Nick Coghlan's formulation, my specific goal here would be close to:

> Documenting what the current upload API between twine & warehouse actually 
> is, similar to the way PEP 503 focused on describing the status quo, without 
> making any changes to it. That way, other servers (like devpi) and other 
> upload clients have the info they need to help ensure interoperability.

Since Warehouse is trying to redo its various APIs in the next several months, 
I think it might be more useful to document and work with the new upload API, 
but I'm open to feedback on this.

After a little conversation here on distutils-sig, I believe my steps would be:

1. start a very early PEP draft with lots of To Be Determined blanks, submit as 
a PR to the python/peps repo, and share it with distutils-sig
2. ping maintainers of related tools
3. discuss with others at the packaging sprints 
https://wiki.python.org/psf/PackagingSprints next week
4. revise and get consensus, preferably mostly on this list
5. finalize PEP and get PEP accepted by BDFL-Delegate
6. coordinate with PyPA, maintainers of `distutils`, maintainers of packaging 
and distribution tools, and documentation maintainers to implement PEP 
compliance

Thoughts are welcome. I originally posted this at 
https://github.com/pypa/packaging-problems/issues/128 .
-- 
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/WEPTF7Q7475UA7VVULDLIG3A445WOCLI/

[Distutils] Re: org-mode README file formats

[Diane Trout]

On Tue, 2018-05-08 at 16:44 +, Brett Cannon wrote:
> On Mon, 7 May 2018 at 16:54 Diane Trout  wrote:
> > Hi,
> > 
> > 
> > 
> > I was building a package where I had a README.org file, which
> > 
> > setuptools couldn't find.
> > 
> > 
> > 
> > It listed .md as a valid format, so I was wondering if org-mode was
> > 
> > sufficiently plain text to be added to the list of accepted README
> > file
> > 
> > formats?
> 
> What's org-mode? Sounds like an Emacs thing based on what I have
> heard Emacs people say. :)
> 
> If it is an Emacs thing then I would vote "no" since that's very
> editor-specific and I suspect trying to support every plaintext file
> format is never-ending.

Well yes, it's certainly most powerful, flexible, and feature complete
with emacs, but there is work on org-mode support in vim and sublime.
Additionally org-mode syntax is supported by GitHub, GitLab, and
pandoc.
https://en.wikipedia.org/wiki/Org-mode#Integration

There's also an argument that org-mode is a good lightweight markup
language in and of itself.
http://karl-voit.at/2017/09/23/orgmode-as-markup-only/

Since it is breaking out of its source community I thought it at least
worth asking about. Out of curiosity, do you have a feeling for how
popular a lightweight markup language needs to be before it gets added
to the list of setuptools recognized formats?

Thanks,
Diane--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/DVC3Q6OXMRJFZ6RZIKUTFRPOI2D65OFR/

[Distutils] Re: org-mode README file formats

[Brett Cannon]

On Mon, 7 May 2018 at 16:54 Diane Trout  wrote:

> Hi,
>
> I was building a package where I had a README.org file, which
> setuptools couldn't find.
>
> It listed .md as a valid format, so I was wondering if org-mode was
> sufficiently plain text to be added to the list of accepted README file
> formats?
>

What's org-mode? Sounds like an Emacs thing based on what I have heard
Emacs people say. :)

If it is an Emacs thing then I would vote "no" since that's very
editor-specific and I suspect trying to support every plaintext file format
is never-ending.

-Brett


>
> For what it's worth, github-markup can handle .org files
> https://github.com/github/markup
>
> Diane
> --
> Distutils-SIG mailing list
> distutils-sig@python.org
> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/7MM57BTQPZBZJ62K3526GBLLOVZONNAA/
>
--
Distutils-SIG mailing list
distutils-sig@python.org
https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/
Message archived at 
https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/UXQWVAUORSYZQQRF4ECZXSFUKXQF3I74/