Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

[Nick Coghlan]

On 4 May 2016 at 04:28, Nathaniel Smith  wrote:
> On Tue, May 3, 2016 at 10:10 AM, Paul Moore  wrote:
>> On 3 May 2016 at 17:47, Donald Stufft  wrote:
>>> It will likely get decided as part of the build system PEP, whenever that
>>> gets picked up again.
>>
>> Yes, but on 15th March
>> (https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
>> Robert posted
>>
>>> Just to set expectations: this whole process seems stalled to me; I'm
>>> going to context switch and focus on things that can move forward.
>>> Someone please ping me when its relevant to put effort in again :).
>>
>> And I think that's right. The whole build system PEP issue appears
>> stalled from a lack of someone willing (or with the time) to make a
>> call on the approach we take.
>
> No, no, Nick's not the blocker. I'm the blocker! (Sorry)

It's been an interesting couple of months, so even if you had got this
post together earlier, it's quite possible we would have ended up
blocked on me anyway :)

> Donald + Robert + I had a longish conversation about this on IRC a
> month ago [1]. I volunteered to summarize back to the mailing list,
> and then I flaked -- so I guess this is that belated email :-).
>
> Here's the tentative conclusions we came to:
>
> Blocker 1 is figuring out what to do about the sdist format. The
> debate is between keeping something that's basically the current
> format, versus somehow cleaning it up (e.g. Donald's "source wheel"
> ideas). To move forward:
> - I'll write up a PEP that attempts to just document/standardize the
> current de facto sdist format and send it to the mailing list
> (basically: filename convention, PKG-INFO + a list of which fields in
> PKG-INFO pypi actually cares about, presence of setup.py), and adds
> some sort of optional-defaulting-to-1 SDist-Version (I guess in a file
> called SDIST by analogy with WHEEL). And also contains a rationale
> section explaining the trade-offs of standardizing this versus
> creating a new extension.)
> - Donald will make his case for the new extension approach on the mailing list
> - We beg Nick to read over both things and make a ruling so we can move on

+1 for just documenting the sdist-we-have-today, and avoiding making
the build system decoupling proposals dependent on any changes to
that. (That's not to say defining a better source format isn't
desirable - it's just a nice-to-have future enhancement, rather than
being essential in the near term)

One of the big reasons I stopped working on metadata 2.0 is that
there's no way for us to force re-releases of everything on PyPI,
which means we need to accommodate already published releases if we
want a new approach to be widely adopted

That's why PEP 440 (particularly its normalisation scheme) was checked
for a high level of pragmatic compatibility against PyPI's existing
contents, why PEP 508's dependency specifier syntax is closer to that
defined by setuptools than it is the PEP 345 one, and why I think
better documenting the current sdist format is the right way forward
here.

> Blocker 2 is figuring out whether the new pip <-> build system "hook"
> interface should be command-line based (like the current draft of PEP
> 516) or Python function call based (like the current draft of PEP
> 517). It sounds like currently Donald and I are in favor of the python
> hooks approach, and Robert is indifferent between them and just wants
> to move forward, so we agreed that unless anyone objects we'll drop
> the command-line approach and go ahead with refining the Python
> function call approach. So... if you want to object then speak up now.

While I'd previously expressed a preference for a command line based
approach, the subsequent discussion persuaded me the Python API was at
least as viable, if not preferable, so I'd be happy to endorse that
approach.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] moving things forward

[Alex Grönholm]

I certainly have no problem with Daniel's suggestion (and it would be 
much better than my solution) but would involve yet more standards work. 
Who's going to do that and when?


03.05.2016, 22:39, Donald Stufft kirjoitti:

On May 3, 2016, at 3:35 PM, Daniel Holth  wrote:

Who cares exactly why it doesn't work? We know how to fix it by doing something 
different (put build dependencies in a static file and have them installed by 
pip before running setup.py).


Presumably Alex would like to know why we can’t implement his suggestion.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



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

Re: [Distutils] moving things forward

[Donald Stufft]

> On May 3, 2016, at 3:35 PM, Daniel Holth  wrote:
> 
> Who cares exactly why it doesn't work? We know how to fix it by doing 
> something different (put build dependencies in a static file and have them 
> installed by pip before running setup.py).
> 

Presumably Alex would like to know why we can’t implement his suggestion.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] moving things forward

[Daniel Holth]

Who cares exactly why it doesn't work? We know how to fix it by doing
something different (put build dependencies in a static file and have them
installed by pip before running setup.py).

On Tue, May 3, 2016 at 3:33 PM Donald Stufft  wrote:

>
> On May 3, 2016, at 3:28 PM, Alex Grönholm 
> wrote:
>
> As I pointed out in my previous post, "extended commands" are not the only
> use case for setup_requires -- upgrading setuptools itself would enable
> support for PEP 508 style conditional requirements. This currently does not
> work because if you have such requirements in your setup(), setuptools will
> fail when parsing those before it even has a chance to act on the minimum
> setuptools requirement specification in setup_requires.
>
>
> I don’t think this would work anyways without some terrible hacks since by
> the time setup_requires have been installed setuptools has already been
> imported so the *old* version will be in sys.modules.
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] moving things forward

[Donald Stufft]

> On May 3, 2016, at 3:28 PM, Alex Grönholm  wrote:
> 
> As I pointed out in my previous post, "extended commands" are not the only 
> use case for setup_requires -- upgrading setuptools itself would enable 
> support for PEP 508 style conditional requirements. This currently does not 
> work because if you have such requirements in your setup(), setuptools will 
> fail when parsing those before it even has a chance to act on the minimum 
> setuptools requirement specification in setup_requires.

I don’t think this would work anyways without some terrible hacks since by the 
time setup_requires have been installed setuptools has already been imported so 
the *old* version will be in sys.modules.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] moving things forward

[Alex Grönholm]

As I pointed out in my previous post, "extended commands" are not the 
only use case for setup_requires -- upgrading setuptools itself would 
enable support for PEP 508 style conditional requirements. This 
currently does not work because if you have such requirements in your 
setup(), setuptools will fail when parsing those before it even has a 
chance to act on the minimum setuptools requirement specification in 
setup_requires.


03.05.2016, 21:33, Daniel Holth kirjoitti:
What happened is that only a half-dozen setuptools experts (I am not 
one of those six people) know how to write an extended command or 
whatever that would actually be able to take advantage of setup 
requirements as implemented by setuptools. Everyone else wants to 
"import x" at the top of setup.py and pass arguments to the setup() 
function. So it would be better to have the installer make that possible.


On Tue, May 3, 2016 at 2:29 PM Alex Grönholm > wrote:


No, setuptools parses the install requirements before acting on
setup requirements. That is the source of the problem. If
setuptools only parsed and acted on setup requirements before even
parsing install requirements, this wouldn't be an issue.


03.05.2016, 21:26, Leonardo Rochael Almeida kirjoitti:



On 3 May 2016 at 15:07, Alex Grönholm > wrote:

Having setuptools process the setup requirements before
parsing install requirements would be a good step forward.
Had that been done before, we could've just added a setup
requirement for a newer setuptools to enable PEP 508
conditional requirements.


Setuptools does process setup requirements before install
requirements. The "chicken and egg" issue with setuptools is
that, most of the time, setup requires are needed to calculate
information that is passed into the `setup()` call itself.

For example information on header files coming from the C api of
`numpy` which is used to build extensions.

This usually means importing code from the packages in "setup
requires" before setuptools has a chance to actually look at it.

A simple fix would be to allow `setup()` keywords to accept
functions as well as direct values and only invoke the functions
when the values are actually needed, but this idea never gained
traction.

Of course, even if this was implemented, it wouldn't help
directly with "setup requiring" a new version of setuptools
itself, unless setuptools detected this situation and reinvoked
setup.py from scratch.

Regards,

Leo


03.05.2016, 21:04, Daniel Holth kirjoitti:

We did separate build from install. Now we just want to be
able to build without [having to emulate] distutils; just
having some dependencies installed before setup.py runs
would also be a great boon.

I'm reading part of this conversation as "a simple
bdist_wheel bug is a reason to do a lot of work
standardizing file formats" which I find unfortunate.

If he is still up for it let Robert implement his own PEP as
the way forward for build system abstraction. The extra PEPs
are just delaying action.

On Tue, May 3, 2016 at 1:11 PM Paul Moore
> wrote:

On 3 May 2016 at 17:47, Donald Stufft > wrote:
> It will likely get decided as part of the build system
PEP, whenever that
> gets picked up again.

Yes, but on 15th March

(https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
Robert posted

> Just to set expectations: this whole process seems
stalled to me; I'm
> going to context switch and focus on things that can
move forward.
> Someone please ping me when its relevant to put effort
in again :).

And I think that's right. The whole build system PEP
issue appears
stalled from a lack of someone willing (or with the
time) to make a
call on the approach we take.

As far as I'm aware, the decision remains with Nick.
With the possible
exception of Donald's proposal (which AFAIK never got
formally
published as a PEP) everything that can be said on the
other proposals
has been said, and the remaining differences are ones of
choice of
approach rather than anything affecting capabilities.
(Robert's
message at

https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
summarised the state of the 3 proposals at 

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

[Paul Moore]

On 3 May 2016 at 19:28, Nathaniel Smith  wrote:
> No, no, Nick's not the blocker. I'm the blocker! (Sorry)
>
> Donald + Robert + I had a longish conversation about this on IRC a
> month ago [1]. I volunteered to summarize back to the mailing list,
> and then I flaked -- so I guess this is that belated email :-).

Not a problem - I'm glad my mail prompted some movement, but I
completely understand that other things can get in the way.

> Here's the tentative conclusions we came to:
>
> Blocker 1 is figuring out what to do about the sdist format. The
> debate is between keeping something that's basically the current
> format, versus somehow cleaning it up (e.g. Donald's "source wheel"
> ideas). To move forward:
> - I'll write up a PEP that attempts to just document/standardize the
> current de facto sdist format and send it to the mailing list
> (basically: filename convention, PKG-INFO + a list of which fields in
> PKG-INFO pypi actually cares about, presence of setup.py), and adds
> some sort of optional-defaulting-to-1 SDist-Version (I guess in a file
> called SDIST by analogy with WHEEL). And also contains a rationale
> section explaining the trade-offs of standardizing this versus
> creating a new extension.)
> - Donald will make his case for the new extension approach on the mailing list
> - We beg Nick to read over both things and make a ruling so we can move on

Even though I was one who wanted a properly defined sdist format, I'm
inclined to be OK with a "whatever works for now" approach, so I don't
see a problem with documenting and tidying up the current de facto
standard. If Donald comes up with a good proposal, that's great - but
if not, we can always revisit that side of things later.

> Blocker 2 is figuring out whether the new pip <-> build system "hook"
> interface should be command-line based (like the current draft of PEP
> 516) or Python function call based (like the current draft of PEP
> 517). It sounds like currently Donald and I are in favor of the python
> hooks approach, and Robert is indifferent between them and just wants
> to move forward, so we agreed that unless anyone objects we'll drop
> the command-line approach and go ahead with refining the Python
> function call approach. So... if you want to object then speak up now.

Cool. No objections from me.

> Then there are a bunch of details to work out about what hooks to
> provide exactly and what their semantics should be, but hopefully once
> we've settled the two issues above that will be an easier discussion
> to have.
>
> So yeah, basically the next step is for me [2] to write up a spec for
> how sdists currently (really) work.
[...]
> [2] Or if someone else wants to raise their hand and volunteer I
> wouldn't object, obviously I am a bit swamped right now :-)

I don't want to volunteer to take this on completely, as I'll probably
not have the time either, but if I can help in any way (research,
proofreading, writing parts of the document) let me know.

Thanks for the update!

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

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

[Brett Cannon]

Thanks for the update! Glad this is still moving forward. I'll continue to
prod the list if things stall again as I want to respond to "Python
packaging is broken" with "actually your knowledge is just outdated, go
read packaging.python.org". :)

On Tue, 3 May 2016 at 11:28 Nathaniel Smith  wrote:

> On Tue, May 3, 2016 at 10:10 AM, Paul Moore  wrote:
> > On 3 May 2016 at 17:47, Donald Stufft  wrote:
> >> It will likely get decided as part of the build system PEP, whenever
> that
> >> gets picked up again.
> >
> > Yes, but on 15th March
> > (https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
> > Robert posted
> >
> >> Just to set expectations: this whole process seems stalled to me; I'm
> >> going to context switch and focus on things that can move forward.
> >> Someone please ping me when its relevant to put effort in again :).
> >
> > And I think that's right. The whole build system PEP issue appears
> > stalled from a lack of someone willing (or with the time) to make a
> > call on the approach we take.
>
> No, no, Nick's not the blocker. I'm the blocker! (Sorry)
>
> Donald + Robert + I had a longish conversation about this on IRC a
> month ago [1]. I volunteered to summarize back to the mailing list,
> and then I flaked -- so I guess this is that belated email :-).
>
> Here's the tentative conclusions we came to:
>
> Blocker 1 is figuring out what to do about the sdist format. The
> debate is between keeping something that's basically the current
> format, versus somehow cleaning it up (e.g. Donald's "source wheel"
> ideas). To move forward:
> - I'll write up a PEP that attempts to just document/standardize the
> current de facto sdist format and send it to the mailing list
> (basically: filename convention, PKG-INFO + a list of which fields in
> PKG-INFO pypi actually cares about, presence of setup.py), and adds
> some sort of optional-defaulting-to-1 SDist-Version (I guess in a file
> called SDIST by analogy with WHEEL). And also contains a rationale
> section explaining the trade-offs of standardizing this versus
> creating a new extension.)
> - Donald will make his case for the new extension approach on the mailing
> list
> - We beg Nick to read over both things and make a ruling so we can move on
>
> Blocker 2 is figuring out whether the new pip <-> build system "hook"
> interface should be command-line based (like the current draft of PEP
> 516) or Python function call based (like the current draft of PEP
> 517). It sounds like currently Donald and I are in favor of the python
> hooks approach, and Robert is indifferent between them and just wants
> to move forward, so we agreed that unless anyone objects we'll drop
> the command-line approach and go ahead with refining the Python
> function call approach. So... if you want to object then speak up now.
>
> Then there are a bunch of details to work out about what hooks to
> provide exactly and what their semantics should be, but hopefully once
> we've settled the two issues above that will be an easier discussion
> to have.
>
> So yeah, basically the next step is for me [2] to write up a spec for
> how sdists currently (really) work.
>
> -n
>
> [1] Logs (split across two pages in the log viewer):
>   http://chat-logs.dcpython.org/day/pypa-dev/2016-03-30#18.23.46.njs
>   http://chat-logs.dcpython.org/day/pypa-dev/2016-03-31#00.29.32.lifeless
> [2] Or if someone else wants to raise their hand and volunteer I
> wouldn't object, obviously I am a bit swamped right now :-)
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] moving things forward

[Daniel Holth]

What happened is that only a half-dozen setuptools experts (I am not one of
those six people) know how to write an extended command or whatever that
would actually be able to take advantage of setup requirements as
implemented by setuptools. Everyone else wants to "import x" at the top of
setup.py and pass arguments to the setup() function. So it would be better
to have the installer make that possible.

On Tue, May 3, 2016 at 2:29 PM Alex Grönholm 
wrote:

> No, setuptools parses the install requirements before acting on setup
> requirements. That is the source of the problem. If setuptools only parsed
> and acted on setup requirements before even parsing install requirements,
> this wouldn't be an issue.
>
>
> 03.05.2016, 21:26, Leonardo Rochael Almeida kirjoitti:
>
>
>
> On 3 May 2016 at 15:07, Alex Grönholm  wrote:
>
>> Having setuptools process the setup requirements before parsing install
>> requirements would be a good step forward. Had that been done before, we
>> could've just added a setup requirement for a newer setuptools to enable
>> PEP 508 conditional requirements.
>>
>
> Setuptools does process setup requirements before install requirements.
> The "chicken and egg" issue with setuptools is that, most of the time,
> setup requires are needed to calculate information that is passed into the
> `setup()` call itself.
>
> For example information on header files coming from the C api of `numpy`
> which is used to build extensions.
>
> This usually means importing code from the packages in "setup requires"
> before setuptools has a chance to actually look at it.
>
> A simple fix would be to allow `setup()` keywords to accept functions as
> well as direct values and only invoke the functions when the values are
> actually needed, but this idea never gained traction.
>
> Of course, even if this was implemented, it wouldn't help directly with
> "setup requiring" a new version of setuptools itself, unless setuptools
> detected this situation and reinvoked setup.py from scratch.
>
> Regards,
>
> Leo
>
>
> 03.05.2016, 21:04, Daniel Holth kirjoitti:
>>
>> We did separate build from install. Now we just want to be able to build
>> without [having to emulate] distutils; just having some dependencies
>> installed before setup.py runs would also be a great boon.
>>
>> I'm reading part of this conversation as "a simple bdist_wheel bug is a
>> reason to do a lot of work standardizing file formats" which I find
>> unfortunate.
>>
>> If he is still up for it let Robert implement his own PEP as the way
>> forward for build system abstraction. The extra PEPs are just delaying
>> action.
>>
>> On Tue, May 3, 2016 at 1:11 PM Paul Moore  wrote:
>>
>>> On 3 May 2016 at 17:47, Donald Stufft  wrote:
>>> > It will likely get decided as part of the build system PEP, whenever
>>> that
>>> > gets picked up again.
>>>
>>> Yes, but on 15th March
>>> (https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
>>> Robert posted
>>>
>>> > Just to set expectations: this whole process seems stalled to me; I'm
>>> > going to context switch and focus on things that can move forward.
>>> > Someone please ping me when its relevant to put effort in again :).
>>>
>>> And I think that's right. The whole build system PEP issue appears
>>> stalled from a lack of someone willing (or with the time) to make a
>>> call on the approach we take.
>>>
>>> As far as I'm aware, the decision remains with Nick. With the possible
>>> exception of Donald's proposal (which AFAIK never got formally
>>> published as a PEP) everything that can be said on the other proposals
>>> has been said, and the remaining differences are ones of choice of
>>> approach rather than anything affecting capabilities. (Robert's
>>> message at
>>> https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
>>> summarised the state of the 3 proposals at the time).
>>>
>>> I think this is something that should be resolved - we don't appear to
>>> be gaining anything by waiting, and until we have a decision on the
>>> approach that's being taken, we aren't going to get anyone writing
>>> code for their preferred option.
>>>
>>> Nick - do you have the time to pick this up? Or does it need someone
>>> to step up as BDFL-delegate? Robert, Nathaniel, do you have time to
>>> spend on a final round of discussion on this, on the assumption that
>>> the goal will be a final decision at the end of it? Donald, do you
>>> have the time and interest to complete and publish your proposal?
>>>
>>> Paul
>>> ___
>>> Distutils-SIG maillist  -  Distutils-SIG@python.org
>>> https://mail.python.org/mailman/listinfo/distutils-sig
>>>
>>
>>
>> ___
>> Distutils-SIG maillist  -  
>> Distutils-SIG@python.orghttps://mail.python.org/mailman/listinfo/distutils-sig
>>
>>
>>
>> 

Re: [Distutils] moving things forward

[Alex Grönholm]

No, setuptools parses the install requirements before acting on setup 
requirements. That is the source of the problem. If setuptools only 
parsed and acted on setup requirements before even parsing install 
requirements, this wouldn't be an issue.


03.05.2016, 21:26, Leonardo Rochael Almeida kirjoitti:



On 3 May 2016 at 15:07, Alex Grönholm > wrote:


Having setuptools process the setup requirements before parsing
install requirements would be a good step forward. Had that been
done before, we could've just added a setup requirement for a
newer setuptools to enable PEP 508 conditional requirements.


Setuptools does process setup requirements before install 
requirements. The "chicken and egg" issue with setuptools is that, 
most of the time, setup requires are needed to calculate information 
that is passed into the `setup()` call itself.


For example information on header files coming from the C api of 
`numpy` which is used to build extensions.


This usually means importing code from the packages in "setup 
requires" before setuptools has a chance to actually look at it.


A simple fix would be to allow `setup()` keywords to accept functions 
as well as direct values and only invoke the functions when the values 
are actually needed, but this idea never gained traction.


Of course, even if this was implemented, it wouldn't help directly 
with "setup requiring" a new version of setuptools itself, unless 
setuptools detected this situation and reinvoked setup.py from scratch.


Regards,

Leo


03.05.2016, 21:04, Daniel Holth kirjoitti:

We did separate build from install. Now we just want to be able
to build without [having to emulate] distutils; just having some
dependencies installed before setup.py runs would also be a great
boon.

I'm reading part of this conversation as "a simple bdist_wheel
bug is a reason to do a lot of work standardizing file formats"
which I find unfortunate.

If he is still up for it let Robert implement his own PEP as the
way forward for build system abstraction. The extra PEPs are just
delaying action.

On Tue, May 3, 2016 at 1:11 PM Paul Moore > wrote:

On 3 May 2016 at 17:47, Donald Stufft > wrote:
> It will likely get decided as part of the build system PEP,
whenever that
> gets picked up again.

Yes, but on 15th March
(https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
Robert posted

> Just to set expectations: this whole process seems stalled
to me; I'm
> going to context switch and focus on things that can move
forward.
> Someone please ping me when its relevant to put effort in
again :).

And I think that's right. The whole build system PEP issue
appears
stalled from a lack of someone willing (or with the time) to
make a
call on the approach we take.

As far as I'm aware, the decision remains with Nick. With the
possible
exception of Donald's proposal (which AFAIK never got formally
published as a PEP) everything that can be said on the other
proposals
has been said, and the remaining differences are ones of
choice of
approach rather than anything affecting capabilities. (Robert's
message at
https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
summarised the state of the 3 proposals at the time).

I think this is something that should be resolved - we don't
appear to
be gaining anything by waiting, and until we have a decision
on the
approach that's being taken, we aren't going to get anyone
writing
code for their preferred option.

Nick - do you have the time to pick this up? Or does it need
someone
to step up as BDFL-delegate? Robert, Nathaniel, do you have
time to
spend on a final round of discussion on this, on the
assumption that
the goal will be a final decision at the end of it? Donald,
do you
have the time and interest to complete and publish your proposal?

Paul
___
Distutils-SIG maillist  - Distutils-SIG@python.org

https://mail.python.org/mailman/listinfo/distutils-sig



___
Distutils-SIG maillist  -Distutils-SIG@python.org 

https://mail.python.org/mailman/listinfo/distutils-sig



___
Distutils-SIG maillist  - Distutils-SIG@python.org

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

[Nathaniel Smith]

On Tue, May 3, 2016 at 10:10 AM, Paul Moore  wrote:
> On 3 May 2016 at 17:47, Donald Stufft  wrote:
>> It will likely get decided as part of the build system PEP, whenever that
>> gets picked up again.
>
> Yes, but on 15th March
> (https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
> Robert posted
>
>> Just to set expectations: this whole process seems stalled to me; I'm
>> going to context switch and focus on things that can move forward.
>> Someone please ping me when its relevant to put effort in again :).
>
> And I think that's right. The whole build system PEP issue appears
> stalled from a lack of someone willing (or with the time) to make a
> call on the approach we take.

No, no, Nick's not the blocker. I'm the blocker! (Sorry)

Donald + Robert + I had a longish conversation about this on IRC a
month ago [1]. I volunteered to summarize back to the mailing list,
and then I flaked -- so I guess this is that belated email :-).

Here's the tentative conclusions we came to:

Blocker 1 is figuring out what to do about the sdist format. The
debate is between keeping something that's basically the current
format, versus somehow cleaning it up (e.g. Donald's "source wheel"
ideas). To move forward:
- I'll write up a PEP that attempts to just document/standardize the
current de facto sdist format and send it to the mailing list
(basically: filename convention, PKG-INFO + a list of which fields in
PKG-INFO pypi actually cares about, presence of setup.py), and adds
some sort of optional-defaulting-to-1 SDist-Version (I guess in a file
called SDIST by analogy with WHEEL). And also contains a rationale
section explaining the trade-offs of standardizing this versus
creating a new extension.)
- Donald will make his case for the new extension approach on the mailing list
- We beg Nick to read over both things and make a ruling so we can move on

Blocker 2 is figuring out whether the new pip <-> build system "hook"
interface should be command-line based (like the current draft of PEP
516) or Python function call based (like the current draft of PEP
517). It sounds like currently Donald and I are in favor of the python
hooks approach, and Robert is indifferent between them and just wants
to move forward, so we agreed that unless anyone objects we'll drop
the command-line approach and go ahead with refining the Python
function call approach. So... if you want to object then speak up now.

Then there are a bunch of details to work out about what hooks to
provide exactly and what their semantics should be, but hopefully once
we've settled the two issues above that will be an easier discussion
to have.

So yeah, basically the next step is for me [2] to write up a spec for
how sdists currently (really) work.

-n

[1] Logs (split across two pages in the log viewer):
  http://chat-logs.dcpython.org/day/pypa-dev/2016-03-30#18.23.46.njs
  http://chat-logs.dcpython.org/day/pypa-dev/2016-03-31#00.29.32.lifeless
[2] Or if someone else wants to raise their hand and volunteer I
wouldn't object, obviously I am a bit swamped right now :-)

-- 
Nathaniel J. Smith -- https://vorpus.org
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

[Daniel Holth]

We did separate build from install. Now we just want to be able to build
without [having to emulate] distutils; just having some dependencies
installed before setup.py runs would also be a great boon.

I'm reading part of this conversation as "a simple bdist_wheel bug is a
reason to do a lot of work standardizing file formats" which I find
unfortunate.

If he is still up for it let Robert implement his own PEP as the way
forward for build system abstraction. The extra PEPs are just delaying
action.

On Tue, May 3, 2016 at 1:11 PM Paul Moore  wrote:

> On 3 May 2016 at 17:47, Donald Stufft  wrote:
> > It will likely get decided as part of the build system PEP, whenever that
> > gets picked up again.
>
> Yes, but on 15th March
> (https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
> Robert posted
>
> > Just to set expectations: this whole process seems stalled to me; I'm
> > going to context switch and focus on things that can move forward.
> > Someone please ping me when its relevant to put effort in again :).
>
> And I think that's right. The whole build system PEP issue appears
> stalled from a lack of someone willing (or with the time) to make a
> call on the approach we take.
>
> As far as I'm aware, the decision remains with Nick. With the possible
> exception of Donald's proposal (which AFAIK never got formally
> published as a PEP) everything that can be said on the other proposals
> has been said, and the remaining differences are ones of choice of
> approach rather than anything affecting capabilities. (Robert's
> message at
> https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
> summarised the state of the 3 proposals at the time).
>
> I think this is something that should be resolved - we don't appear to
> be gaining anything by waiting, and until we have a decision on the
> approach that's being taken, we aren't going to get anyone writing
> code for their preferred option.
>
> Nick - do you have the time to pick this up? Or does it need someone
> to step up as BDFL-delegate? Robert, Nathaniel, do you have time to
> spend on a final round of discussion on this, on the assumption that
> the goal will be a final decision at the end of it? Donald, do you
> have the time and interest to complete and publish your proposal?
>
> Paul
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] moving things forward

[Alex Grönholm]

Having setuptools process the setup requirements before parsing install 
requirements would be a good step forward. Had that been done before, we 
could've just added a setup requirement for a newer setuptools to enable 
PEP 508 conditional requirements.


03.05.2016, 21:04, Daniel Holth kirjoitti:
We did separate build from install. Now we just want to be able to 
build without [having to emulate] distutils; just having some 
dependencies installed before setup.py runs would also be a great boon.


I'm reading part of this conversation as "a simple bdist_wheel bug is 
a reason to do a lot of work standardizing file formats" which I find 
unfortunate.


If he is still up for it let Robert implement his own PEP as the way 
forward for build system abstraction. The extra PEPs are just delaying 
action.


On Tue, May 3, 2016 at 1:11 PM Paul Moore > wrote:


On 3 May 2016 at 17:47, Donald Stufft > wrote:
> It will likely get decided as part of the build system PEP,
whenever that
> gets picked up again.

Yes, but on 15th March
(https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
Robert posted

> Just to set expectations: this whole process seems stalled to
me; I'm
> going to context switch and focus on things that can move forward.
> Someone please ping me when its relevant to put effort in again :).

And I think that's right. The whole build system PEP issue appears
stalled from a lack of someone willing (or with the time) to make a
call on the approach we take.

As far as I'm aware, the decision remains with Nick. With the possible
exception of Donald's proposal (which AFAIK never got formally
published as a PEP) everything that can be said on the other proposals
has been said, and the remaining differences are ones of choice of
approach rather than anything affecting capabilities. (Robert's
message at
https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
summarised the state of the 3 proposals at the time).

I think this is something that should be resolved - we don't appear to
be gaining anything by waiting, and until we have a decision on the
approach that's being taken, we aren't going to get anyone writing
code for their preferred option.

Nick - do you have the time to pick this up? Or does it need someone
to step up as BDFL-delegate? Robert, Nathaniel, do you have time to
spend on a final round of discussion on this, on the assumption that
the goal will be a final decision at the end of it? Donald, do you
have the time and interest to complete and publish your proposal?

Paul
___
Distutils-SIG maillist  - Distutils-SIG@python.org

https://mail.python.org/mailman/listinfo/distutils-sig



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


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

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

[Ian Cordasco]

On Tue, May 3, 2016 at 12:10 PM, Paul Moore  wrote:
> On 3 May 2016 at 17:47, Donald Stufft  wrote:
>> It will likely get decided as part of the build system PEP, whenever that
>> gets picked up again.
>
> Yes, but on 15th March
> (https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
> Robert posted
>
>> Just to set expectations: this whole process seems stalled to me; I'm
>> going to context switch and focus on things that can move forward.
>> Someone please ping me when its relevant to put effort in again :).
>
> And I think that's right. The whole build system PEP issue appears
> stalled from a lack of someone willing (or with the time) to make a
> call on the approach we take.
>
> As far as I'm aware, the decision remains with Nick. With the possible
> exception of Donald's proposal (which AFAIK never got formally
> published as a PEP) everything that can be said on the other proposals
> has been said, and the remaining differences are ones of choice of
> approach rather than anything affecting capabilities. (Robert's
> message at 
> https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
> summarised the state of the 3 proposals at the time).
>
> I think this is something that should be resolved - we don't appear to
> be gaining anything by waiting, and until we have a decision on the
> approach that's being taken, we aren't going to get anyone writing
> code for their preferred option.
>
> Nick - do you have the time to pick this up? Or does it need someone
> to step up as BDFL-delegate? Robert, Nathaniel, do you have time to
> spend on a final round of discussion on this, on the assumption that
> the goal will be a final decision at the end of it? Donald, do you
> have the time and interest to complete and publish your proposal?
>
> Paul


I was following that PEP and going to implement it in Twine for the
PyPA. If it would help, I can help Nick with this process. I read both
PEPs a while ago and I think updates have been made so I'd need to
read them again, but I can probably make some time for this.

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

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

[Paul Moore]

On 3 May 2016 at 17:47, Donald Stufft  wrote:
> It will likely get decided as part of the build system PEP, whenever that
> gets picked up again.

Yes, but on 15th March
(https://mail.python.org/pipermail/distutils-sig/2016-March/028457.html)
Robert posted

> Just to set expectations: this whole process seems stalled to me; I'm
> going to context switch and focus on things that can move forward.
> Someone please ping me when its relevant to put effort in again :).

And I think that's right. The whole build system PEP issue appears
stalled from a lack of someone willing (or with the time) to make a
call on the approach we take.

As far as I'm aware, the decision remains with Nick. With the possible
exception of Donald's proposal (which AFAIK never got formally
published as a PEP) everything that can be said on the other proposals
has been said, and the remaining differences are ones of choice of
approach rather than anything affecting capabilities. (Robert's
message at 
https://mail.python.org/pipermail/distutils-sig/2016-March/028437.html
summarised the state of the 3 proposals at the time).

I think this is something that should be resolved - we don't appear to
be gaining anything by waiting, and until we have a decision on the
approach that's being taken, we aren't going to get anyone writing
code for their preferred option.

Nick - do you have the time to pick this up? Or does it need someone
to step up as BDFL-delegate? Robert, Nathaniel, do you have time to
spend on a final round of discussion on this, on the assumption that
the goal will be a final decision at the end of it? Donald, do you
have the time and interest to complete and publish your proposal?

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

[Distutils] moving things forward (was: wheel including files it shouldn't)

[Brett Cannon]

On Wed, 27 Apr 2016 at 10:53 Donald Stufft  wrote:

> This isn't really a problem with what you're doing. Rather it's an issue
> with the toolchain and and open question whether or not wheels should
> conceptually be able to be produced from a checkout, or if they should only
> be produced from a sdist. Problems like this are why I advocate the
> Checkout -> sdist -> wheel being the only path, but others feel differently.
>

And Daniel Holth said he did feel differently, so obviously this hasn't
moved forward in terms of finding consensus.

Where does all of this sit in regards to trying to separate building from
installation? From my perspective as mailing list lurker, it's sitting at
an impasse as Nick hasn't made a final call nor has a BDFL delegate on the
topic been chosen to settle the matter (obviously if I missed something
then please let me know). Could we choose a Great Decider on this topic of
build/installation separation and get final RFC/PEPs written so we can get
passed this impasse and move forward?

-Brett


>
>
> — Donald Stufft
>
> On Apr 27 2016, at 1:38 pm, Ethan Furman  wrote:
>
>> On 04/26/2016 07:10 AM, Donald Stufft wrote:
>>
>> > Alternatively, he could have just produced a wheel from any checkout at
>> > all if the MANIFEST.in excluded a file that would otherwise have been
>> > installed.
>>
>> Yes. My MANIFEST.in starts with an 'exclude enum/*' and then includes
>> all files it wants.
>>
>> > This sort of thing is why I'm an advocate that we should only
>> > build sdists from checkouts, and wheels from sdists (at the low level
>> > anyways, even if the UI allows people to appear to create a wheel
>> > straight from a checkout).
>>
>> My current process is:
>>
>>python3.5 setup.py sdist --format=gztar,zip bdist_wheel upload
>>
>> What should I be doing instead?
>>
>> --
>> ~Ethan~
>>
>> ___
>> Distutils-SIG maillist - Distutils-SIG@python.org
>> https://mail.python.org/mailman/listinfo/distutils-sig
>>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Basic Markdown Readme Support

[Donald Stufft]

> On May 3, 2016, at 9:47 AM, Nick Coghlan  wrote:
> 
> On 3 May 2016 at 23:18, Fred Drake  wrote:
>> My perspective, for what it's worth, is that while I find Markdown a
>> horrible pain, there are a lot of people who pick it up before picking
>> up Python, and tools like GitHub and BitBucket  encourage (and make it
>> easier to add) README.md to a project. For someone who isn't familiar
>> with reStructuredText, it's an easier on-ramp.
>> 
>> So while I'm all for encouraging developers to prefer
>> reStructuredText, I'm in favor of supporting Markdown as a
>> long_description format. The format for a README file just doesn't
>> seem such a big deal that alienating potential community members is
>> worth it.
> 
> Exactly. The lack of support for Markdown README files is mainly a
> matter of a historical quirk of the way the PyPI metadata upload API
> works making this way more work to implement than it seems at first
> glance, the current PyPI codebase being sufficiently fragile that we
> actively avoid changing it, and getting Warehouse to the point of
> being sufficiently feature complete for it to take over primary
> service responsibilities being a long hard slog for the folks working
> on it (it's a lot harder to find volunteers interested in working on
> paying down technical debt than it is to find folks that want to work
> on new user facing features).

This is basically the answer here. It looks like the original post by Nick
Timkovich tried to start a discussion about what this might look like, but
really I think it focused too much on the setup.py API which isn't really the
issue, we can do whatever there, what's more the issue is how is that
represented in the metadata.

Right now we have a singular metadata field which just contains all of the text
of the long_description without any other information about it. The simplest
thing to do is probably to just add a new field, something like::

Description-Markup: 

We'd need to define some values for for it like "txt", "md", "rst" or something
along those lines. I'd suggest extensions so that in the future we can move
the long description into it's own file in the metadata and just move that
value to the file extension (like `DESCRIPTION.[ext]`). We'd also want to
declare what behavior should be expected when that value doesn't exist
(codifying the current behavior of, attempt to register as rst, fall back to
txt).

We'd probably also want some recommendations on what the different types of
tools should do when encountering invalid markup for the declared markup
language and also what they should do when encountering a markup language they
don't know. For the server side (e.g. PyPI) I'd suggest erroring the upload
whenever an invalid or unknown markup is attempted to be uploaded (where a
undeclined markup is never invalid, it just does the fallback) and for anything
clientside it jsut falls back to plaintext.

This has a few benefits:

* No more ugly when plaintext (or markdown!) accidently get rendered wrongly as
  restructeredtext.
* We can hard fail uploads when their rendering is broken, leading people to
  be able to fix the problems instead of ending up with a bunch of broken
  markup all over PyPI.
* We can allow markup languages other than txt and rst.

However, I'm not going to have time or motivation to really work this into a
valid spec or even a fully fleshed out idea. Nor will I be able to handle
implementing this in PyPI or Warehouse right now since I'm primarily focused on
trying to get Warehouse itself deployed for real. I am happy to review PRs and
actual specs though, whether they take this idea or they use a different one.

> 
> However, this SO answer provides some ideas on ways to convert from
> Markdown to reStructured Text when producing the sdist metadata, or to
> derive a checked in .rst file from a README.md file:
> http://stackoverflow.com/questions/10718767/have-the-same-readme-both-in-markdown-and-restructuredtext
> 
> It is also seems plausible to me that a client-side solution could be
> designed that allowed the description metadata stored in the sdist to
> be overridden when uploading to PyPI (i.e. the description in PKG-INFO
> could be Markdown, but the upload tool could use pypandoc to convert
> that to reStructuredText in the uploaded metadata). I'm not sure if
> Donald would be open to that in twine (presumably via an extra to
> avoid having pypandoc as a standard dependency), but client-only
> changes are generally an easier pitch than changes to the interfaces
> between client tools and PyPI.
> 

I actually mostly don’t do much with twine anymore, Ian Cordasco has more or
less taken over maintenance of it so it'd be up to him ultimately. That being
said I think doing it in twine is the wrong layer. Ideally the metadata in
PyPI matches the metadata in the file and people can "recreate" the PyPI
database using nothing but the files [1].

I think if you want to shim 

Re: [Distutils] Basic Markdown Readme Support

[Wayne Werner]

On Tue, 3 May 2016, Jim Fulton wrote:

In my last job, I had to use a suite of tools (from a single company
that I won't name but is easy to guess :) )  for which no 2 tools used
the same dialect of Markdown. :(

Which begs the question, which dialect of Markdown are you suggesting
we support. :)


My personal preference is CommonMark - mainly because it's actually 
well-defined. There are only a couple of cases that I've encountered where 
CommonMark didn't render exactly what I expected. But at least it's 
consistent, so it doesn't take much to adjust to.



For a simple README, I actually *prefer* CommonMark/Markdown - I find it 
has all the features I need. Of course for more complicated documentation, 
reStructuredText has a lot more power, so I'm down with the extra 
complexity. Plus, I have actually come across more than one project on 
pypi right now where the readme is in markdown format, so looks fine on 
Github, but pretty funky on pypi.


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

Re: [Distutils] Basic Markdown Readme Support

[Fred Drake]

On Tue, May 3, 2016 at 9:29 AM, Jim Fulton  wrote:
> But wait, it's worse. Unlike ReStructuredText, there's no Markdown standard.

We agree that this is a problem, and it's why I don't use Markdown
when tools don't force it.

> In my last job, I had to use a suite of tools (from a single company
> that I won't name but is easy to guess :) )  for which no 2 tools used
> the same dialect of Markdown. :(

Truly a joy.  I'm glad things are better now.  :-)

> Which begs the question, which dialect of Markdown are you suggesting
> we support. :)

If we go with Nick's idea of a client-side solution, we really don't
have to pick just one flavor, though I'd expect GFM would win out for
practical purposes.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Basic Markdown Readme Support

[Nick Coghlan]

On 3 May 2016 at 23:18, Fred Drake  wrote:
> My perspective, for what it's worth, is that while I find Markdown a
> horrible pain, there are a lot of people who pick it up before picking
> up Python, and tools like GitHub and BitBucket  encourage (and make it
> easier to add) README.md to a project. For someone who isn't familiar
> with reStructuredText, it's an easier on-ramp.
>
> So while I'm all for encouraging developers to prefer
> reStructuredText, I'm in favor of supporting Markdown as a
> long_description format. The format for a README file just doesn't
> seem such a big deal that alienating potential community members is
> worth it.

Exactly. The lack of support for Markdown README files is mainly a
matter of a historical quirk of the way the PyPI metadata upload API
works making this way more work to implement than it seems at first
glance, the current PyPI codebase being sufficiently fragile that we
actively avoid changing it, and getting Warehouse to the point of
being sufficiently feature complete for it to take over primary
service responsibilities being a long hard slog for the folks working
on it (it's a lot harder to find volunteers interested in working on
paying down technical debt than it is to find folks that want to work
on new user facing features).

However, this SO answer provides some ideas on ways to convert from
Markdown to reStructured Text when producing the sdist metadata, or to
derive a checked in .rst file from a README.md file:
http://stackoverflow.com/questions/10718767/have-the-same-readme-both-in-markdown-and-restructuredtext

It is also seems plausible to me that a client-side solution could be
designed that allowed the description metadata stored in the sdist to
be overridden when uploading to PyPI (i.e. the description in PKG-INFO
could be Markdown, but the upload tool could use pypandoc to convert
that to reStructuredText in the uploaded metadata). I'm not sure if
Donald would be open to that in twine (presumably via an extra to
avoid having pypandoc as a standard dependency), but client-only
changes are generally an easier pitch than changes to the interfaces
between client tools and PyPI.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Basic Markdown Readme Support

[Paul Moore]

On 3 May 2016 at 14:18, Fred Drake  wrote:
> My perspective, for what it's worth, is that while I find Markdown a
> horrible pain, there are a lot of people who pick it up before picking
> up Python, and tools like GitHub and BitBucket  encourage (and make it
> easier to add) README.md to a project. For someone who isn't familiar
> with reStructuredText, it's an easier on-ramp.
>
> So while I'm all for encouraging developers to prefer
> reStructuredText, I'm in favor of supporting Markdown as a
> long_description format. The format for a README file just doesn't
> seem such a big deal that alienating potential community members is
> worth it.

Agreed. And like it or not, people get familiar with Markdown from
things like github comment boxes, so it's very easy to just "go with
the familiar option".

Having said that, someone still needs to do the work to add Markdown
support - and that's not trivial, as it will involve changes to how
the metadata is held to include a content type for the
long_description. And that means a discussion on how to include that.
So while I don't mind if people want this support, it's not going to
happen unless someone actually goes through the work of managing the
proposal, co-ordinating the discussions, writing the code, etc. And I
suspect that this is unlikely to be a priority of any of the PyPA team
in the near future - so it'll need someone who's interested in seeing
this feature added to take on that work.

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

Re: [Distutils] Basic Markdown Readme Support

[Jim Fulton]

On Tue, May 3, 2016 at 9:18 AM, Fred Drake  wrote:
> My perspective, for what it's worth, is that while I find Markdown a
> horrible pain,

But wait, it's worse. Unlike ReStructuredText, there's no Markdown standard.

In my last job, I had to use a suite of tools (from a single company
that I won't name but is easy to guess :) )  for which no 2 tools used
the same dialect of Markdown. :(

...

> So while I'm all for encouraging developers to prefer
> reStructuredText, I'm in favor of supporting Markdown as a
> long_description format. The format for a README file just doesn't
> seem such a big deal that alienating potential community members is
> worth it.

Which begs the question, which dialect of Markdown are you suggesting
we support. :)

Jim

-- 
Jim Fulton
http://jimfulton.info
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Basic Markdown Readme Support

[Fred Drake]

My perspective, for what it's worth, is that while I find Markdown a
horrible pain, there are a lot of people who pick it up before picking
up Python, and tools like GitHub and BitBucket  encourage (and make it
easier to add) README.md to a project. For someone who isn't familiar
with reStructuredText, it's an easier on-ramp.

So while I'm all for encouraging developers to prefer
reStructuredText, I'm in favor of supporting Markdown as a
long_description format. The format for a README file just doesn't
seem such a big deal that alienating potential community members is
worth it.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Basic Markdown Readme Support

[tritium-list]

> -Original Message-
> From: Nick Coghlan [mailto:ncogh...@gmail.com]
> As I understand it, it's more a matter of folks finding the context
> switch between Markdown and non-Sphinx reStructuredText a pain (with
> the main differences being double-backticks for inline code and `link
> text `_ instead of [link text](link target) for
> hyperlinks) and not being aware of (or caring about) the dire lack of
> commercial investment in tooling support for upstream Python software
> distribution (since all the redistributors have their own software
> distribution platforms that they recommend their users use instead).

As someone who writes quite a bit of non-sphinx Restructured Text, and a lot of 
Markdown (because I have to), I have zero sympathy for the argument of context 
switching.  I can come up with an overblown analogy, but I will just reduce it 
to "it's not complicated to keep the two syntaxes straight".

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

Re: [Distutils] Basic Markdown Readme Support

[Nick Coghlan]

On 3 May 2016 at 14:33, Alexander Walters  wrote:
> The justification was "Because Github et. al. support markdown, pypi should
> too", presumably for the purpose of allowing one to write their README once,
> and have it work in both places.  This is already possible, and only adds
> unneeded complexity to an already complex system.  If you want to make your
> README a write-once document, use the format already supported on both
> platforms.

As I understand it, it's more a matter of folks finding the context
switch between Markdown and non-Sphinx reStructuredText a pain (with
the main differences being double-backticks for inline code and `link
text `_ instead of [link text](link target) for
hyperlinks) and not being aware of (or caring about) the dire lack of
commercial investment in tooling support for upstream Python software
distribution (since all the redistributors have their own software
distribution platforms that they recommend their users use instead).

Encountering volunteer maintained community services can be quite a
shock to the system for folks otherwise used to software tooling
developed by venture capital backed companies making a landgrab for
developer mindshare in the hopes of creating the next Oracle or
Microsoft :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig