On Fri, Jul 28, 2017 at 7:12 PM Nathaniel Smith wrote:
> On Fri, Jul 28, 2017 at 1:58 PM, Thomas Kluyver
> wrote:
> > I think this was actually a question that someone (Nathaniel?) brought
> up:
> > is the project source directory on sys.path when the backend is loaded? I
> > would lean yes, so
On Fri, Jul 28, 2017 at 1:58 PM, Thomas Kluyver wrote:
> I think this was actually a question that someone (Nathaniel?) brought up:
> is the project source directory on sys.path when the backend is loaded? I
> would lean yes, so that it's possible to have a custom backend in the
> project tree, bu
Thomas Kluyver wrote:
I'd like us to circle back round and reconsider allowing projects to
specify 'use tool X to make wheels, and tool Y to make sdists'.
Seems to me this wouldn't strictly need to be part of the
spec, as it could be provided by a multiplexing backend
that relays operations to
Yes, the cwd strongly should be on sys.path, so many possibilities, and we
are used to that behavior in setup.py.
On Fri, Jul 28, 2017 at 4:59 PM Thomas Kluyver wrote:
> On Fri, Jul 28, 2017, at 09:37 PM, Daniel Holth wrote:
>
> See how trivial it would be to put the delegated sdist generator in
> On Jul 28, 2017, at 3:53 PM, Thomas Kluyver wrote:
>
> On Fri, Jul 28, 2017, at 04:16 PM, Daniel Holth wrote:
>> It looks like we've run out of things to say about PEP 517, except, how soon
>> can we get it into pip?
>
> I admire your optimism! ;-)
>
> While I partly hope that I get a unani
On Fri, Jul 28, 2017, at 09:37 PM, Daniel Holth wrote:
> See how trivial it would be to put the delegated sdist generator into the
> build-backend within the confines of the current PEP?
I agree that delegation within the backend is a reasonable answer to this.
> The build-backend could point to a
On 28 July 2017 at 20:53, Thomas Kluyver wrote:
> So I'd like us to circle back round and reconsider allowing projects to
> specify 'use tool X to make wheels, and tool Y to make sdists'. If everyone
> else thinks that's unnecessary, I think we'd all be glad to finish this
> discussion up, but thi
See how trivial it would be to put the delegated sdist generator into the
build-backend within the confines of the current PEP? The build-backend
could point to a .py in the current directory that implements itself with
different tools, or a delegating build backend could parse a separate
source-ba
Hi Thomas,
On 28 July 2017 at 16:53, Thomas Kluyver wrote:
>
> [...] I have a nagging concern about something that someone mentioned ages
> ago: does it make sense for building sdists and building wheels to be part
> of the same backend?
>
> [...]
>
> So I'd like us to circle back round and reco
I'm not worried about it. If you can generate sdist the file format is
simple, if you cannot then the build tool asks you for a wheel. Build tools
can have dependencies too and could depend on a nifty sdist generating
library. It seems to me that the whole spec lets you start by figuring out
how to
On Fri, Jul 28, 2017, at 04:16 PM, Daniel Holth wrote:
> It looks like we've run out of things to say about PEP 517, except, how soon
> can we get it into pip?
I admire your optimism! ;-)
While I partly hope that I get a unanimous disagreement, as it would be
simpler, I have a nagging concern ab
It looks like we've run out of things to say about PEP 517, except, how
soon can we get it into pip? These function signatures will serve us well,
significantly lowering the barrier to entry for new pip-compatible build
systems.
On Thu, Jul 20, 2017 at 3:36 PM Brett Cannon wrote:
> On Thu, 20 Ju
Nick Coghlan writes:
> That would make the following the lowest impact resolution that still
> fixes the original reported problem:
>
> - update the ConfigParser (3.x) and SafeConfigParser (2.x) docs to
> explicitly say that "%%" works as an escape
> - update setuptools and distutils to use SafeC
On 28 July 2017 at 15:39, Robert Collins wrote:
> On 28 July 2017 at 15:34, Nick Coghlan wrote:
>> Clarifying to add: I think this is a worthwhile change, as it helps to
>> ensure that the static config files actually *are* static, and hence
>> less dependent on being read specifically with Pytho
14 matches
Mail list logo