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

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

Re: [Distutils] moving things forward

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

Re: [Distutils] moving things forward

> 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

Re: [Distutils] moving things forward

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

Re: [Distutils] moving things forward

> 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

Re: [Distutils] moving things forward

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

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

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

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

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

Re: [Distutils] moving things forward

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

Re: [Distutils] moving things forward

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

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

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 >

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

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

Re: [Distutils] moving things forward

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

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

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 >

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

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

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

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 >

Re: [Distutils] Basic Markdown Readme Support

> 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,

Re: [Distutils] Basic Markdown Readme Support

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. :)

Re: [Distutils] Basic Markdown Readme Support

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

Re: [Distutils] Basic Markdown Readme Support

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)

Re: [Distutils] Basic Markdown Readme Support

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)

Re: [Distutils] Basic Markdown Readme Support

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

Re: [Distutils] Basic Markdown Readme Support

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

Re: [Distutils] Basic Markdown Readme Support

> -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

Re: [Distutils] Basic Markdown Readme Support

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