On 10 December 2015 at 22:28, M.-A. Lemburg wrote:
> In all this discussion, please don't forget that distutils and
> setuptools differentiate between building the code and creating
> a distribution file.
> The later is not restricted to just the sdist and wheel formats.
> distutils can create
In all this discussion, please don't forget that distutils and
setuptools differentiate between building the code and creating
a distribution file.
The later is not restricted to just the sdist and wheel formats.
distutils can create a wide variety of other distribution formats
such as MSI files,
On 10 December 2015 at 07:17, Robert Collins wrote:
> On 10 December 2015 at 10:07, Donald Stufft wrote:
>> If we consider the setuptools/distutils era to be “Make it Work”, then we’re
>> now at “Make it Right”, making it fast can come later but sacrificing
>> correctness for speed isn’t someth
On 10 December 2015 at 10:07, Donald Stufft wrote:
>
>> On Dec 9, 2015, at 3:56 PM, Robert Collins wrote:
>>
>> On 10 December 2015 at 08:59, Ralf Gommers wrote:
>>>
And even modern pips
can be told *not to call wheel*.
>>>
>>>
>>> Isn't that something you can ignore? If the plan for p
> On Dec 9, 2015, at 3:56 PM, Robert Collins wrote:
>
> On 10 December 2015 at 08:59, Ralf Gommers wrote:
>>
>>> And even modern pips
>>> can be told *not to call wheel*.
>>
>>
>> Isn't that something you can ignore? If the plan for pip anyway is to always
>> go sdist-wheel-install, why supp
On 10 December 2015 at 08:59, Ralf Gommers wrote:
>
>
> On Wed, Dec 9, 2015 at 2:55 AM, Robert Collins
> wrote:
>>
>> Updated - tl;dr:
>>
>> The thing I'm least happy about is that implementing install support
>> will require recursively calling back into pip, that or reimplementing
>> the instal
On Wed, Dec 9, 2015 at 2:55 AM, Robert Collins
wrote:
> Updated - tl;dr:
>
> The thing I'm least happy about is that implementing install support
> will require recursively calling back into pip, that or reimplementing
> the installation of wheels logic from within pip - because
> sufficiently ol
Updated - tl;dr:
- specify encoding of stdout streams that matter
- change build command template to a list of strings so we don't need
to attempt to address shell escaping for paths with spaces(or other
such things)
- be clear about which variables apply in command templating, and
which are enviro
Updated with:
- the pep 0508 reference
- reviews from github
- document --prefix and --root to develop.
-Rob
diff --git a/build-system-abstraction.rst b/build-system-abstraction.rst
index d36b7d5..762cd88 100644
--- a/build-system-abstraction.rst
+++ b/build-system-abstraction.rst
@@ -40,9 +40
On 18 November 2015 at 04:20, Daniel Holth wrote:
> LGTM
>
> Q: Why is build_command a list?
I misread the question - fixed.
diff --git a/build-system-abstraction.rst b/build-system-abstraction.rst
index 8eb0681..d36b7d5 100644
--- a/build-system-abstraction.rst
+++ b/build-system-abstraction.rs
On 18 November 2015 at 05:28, Leonardo Rochael Almeida
wrote:
> On 17 November 2015 at 13:20, Daniel Holth wrote:
>>
>> LGTM
>>
>> Q: Why is build_command a list?
>> Q: Why isn't the file name venezuelanbeavercheese.json instead of
>> pypa.json?
>
>
> Or why not just use a specific key in setup.c
On 18 November 2015 at 04:20, Daniel Holth wrote:
> LGTM
>
> Q: Why is build_command a list?
Because the dependency spec framing we established doesn't describe
multiple dependencies in one string (and we chose to write one that
can be embedded in different higher layer things specifically to all
On 18 November 2015 at 03:27, Antoine Pitrou wrote:
> On Tue, 17 Nov 2015 15:24:04 +1300
> Robert Collins wrote:
>>
>> The programmatic interface allows decoupling of pip from its current
>> hard dependency on setuptools [#setuptools]_ able for two
>> key reasons:
>>
>> 1. It enables new build sy
On 17 November 2015 at 13:20, Daniel Holth wrote:
> LGTM
>
> Q: Why is build_command a list?
> Q: Why isn't the file name venezuelanbeavercheese.json instead of
> pypa.json?
>
Or why not just use a specific key in setup.cfg instead of a pypa.json
file? ISTM that this PEP expects to find in pypa.
LGTM
Q: Why is build_command a list?
Q: Why isn't the file name venezuelanbeavercheese.json instead of pypa.json?
On Tue, Nov 17, 2015 at 10:06 AM Antoine Pitrou wrote:
> On Tue, 17 Nov 2015 09:33:56 -0500
> Donald Stufft wrote:
> >
> > > On Nov 17, 2015, at 9:27 AM, Antoine Pitrou
> wrote:
>
On Tue, 17 Nov 2015 09:33:56 -0500
Donald Stufft wrote:
>
> > On Nov 17, 2015, at 9:27 AM, Antoine Pitrou wrote:
> >
> >>
> >> There are a number of separate subcommands that build systems must support.
> >
> > I wonder how desirable and viable this all is. Desirable, because you
> > are stil
> On Nov 17, 2015, at 9:27 AM, Antoine Pitrou wrote:
>
>>
>> There are a number of separate subcommands that build systems must support.
>
> I wonder how desirable and viable this all is. Desirable, because you
> are still asking the build system to appear as setuptools *in some way*.
> Viable
On Tue, 17 Nov 2015 15:24:04 +1300
Robert Collins wrote:
>
> The programmatic interface allows decoupling of pip from its current
> hard dependency on setuptools [#setuptools]_ able for two
> key reasons:
>
> 1. It enables new build systems that may be much easier to use without
>requiring t
I forgot to reply to the list, so I re-added it
To further explain, in my setuptools replacement experiment I implement the
develop command by generating a a wheel
Using a local version tag `+develop`,
Instead of the actual code, for each top-level it contains a shim python file
that will load
This is the update I promised...full prose, since enough has changed
that a diff would be noise.
:PEP: XX
:Title: Build system abstraction for pip/conda etc
:Version: $Revision$
:Last-Modified: $Date$
:Author: Robert Collins ,
Nathaniel Smith
:BDFL-Delegate: Donald Stufft
:Discussions-T
Now that the dependent spec is up for review, I've refreshed this
build system abstraction one.
Key changes:
- pep-426 -> wheel METADATA files as the distribution description interface
- dropped yaml for JSON as its in the stdlib
I've kept the indirection via a build system rather than adopting
On Tue, Oct 27, 2015 at 12:23 AM, Robert Collins
wrote:
> On 27 October 2015 at 10:32, Ralf Gommers wrote:
> >
>
> > (2) Complex example: to build a Scipy wheel on Windows with MinGW the
> > command is ``python setup.py config --compiler=mingw32 build
> > --compiler=mingw32 bdist_wheel``.
>
> S
On 30 October 2015 at 00:33, Marcus Smith wrote:
>>
>> > 4) Although using a process interface is not necessarily a problem, I
>> > don't
>> > agree with your point on why a python interface would be unworkable.
>> > You're
>> > assuming that pip would try to import all the build tools (for every
>
>
> pip doesn't necessarily have to "interact with many different versions of
> the same build tool during a single invocation" if for example it's
> subprocessing the interactions to some "pip-build" tool that handles the
> imports and use of the python API. I.e. pips calls some "pip-build" too
>
>
> > 4) Although using a process interface is not necessarily a problem, I
> don't
> > agree with your point on why a python interface would be unworkable.
> You're
> > assuming that pip would try to import all the build tools (for every
> > dependency it's processing) in the master process. An
On 28 October 2015 at 06:34, Robert Collins wrote:
>> 1) *Please*, *please*, *please* let's start doing PEP conversations as PRs
>> to pypa/interoperability-peps : ) There's a place in there for unnumbered
>> PEPs. Review will be better and faster IMO as PRs. If the PR gets too
>> cluttered w
On 28 October 2015 at 18:03, Nathaniel Smith wrote:
> On Sun, Oct 25, 2015 at 11:01 PM, Robert Collins
> wrote:
...
>> I've run it past Donald and he has a number of concerns - I think
>> we'll need to discuss them here, and possibly in another hangout, to
>> get a path forward.
>
> Now that I've
On 28 October 2015 at 17:50, Marcus Smith wrote:
>>
>> Current draft text in rendered form at:
>> https://gist.github.com/rbtcollins/666c12aec869237f7cf7
>>
>
> Thanks for working on this.
> Overall I like the idea, but have some comments/questions
>
>
> 1) *Please*, *please*, *please* let's star
On 28 October 2015 at 02:28, Daniel Holth wrote:
> It looks like you would normally be able to say just 'flit' in the
> bootstrap-requires or provided-by, unless the requirements were for build
> code bundled inside the sdist.
Right - you'd say flit in bootstrap-requires, and pip would cache
base
On Oct 27, 2015 10:58 PM, "Ralf Gommers" wrote:
>
>
>
> On Wed, Oct 28, 2015 at 6:03 AM, Nathaniel Smith wrote:
>>
>> On Sun, Oct 25, 2015 at 11:01 PM, Robert Collins
>> wrote:
>> > Since Nathaniel seems busy, I've taken the liberty of drafting a
>> > narrow PEP based on the conversations that a
On Wed, Oct 28, 2015 at 6:03 AM, Nathaniel Smith wrote:
> On Sun, Oct 25, 2015 at 11:01 PM, Robert Collins
> wrote:
> > Since Nathaniel seems busy, I've taken the liberty of drafting a
> > narrow PEP based on the conversations that arose from the prior
> > discussion.
> >
> > It (naturally) has
On Sun, Oct 25, 2015 at 11:01 PM, Robert Collins
wrote:
> Since Nathaniel seems busy, I've taken the liberty of drafting a
> narrow PEP based on the conversations that arose from the prior
> discussion.
>
> It (naturally) has my unique flavor, but builds on the work Nathaniel
> had put together, s
>
>
> Current draft text in rendered form at:
> https://gist.github.com/rbtcollins/666c12aec869237f7cf7
>
>
Thanks for working on this.
Overall I like the idea, but have some comments/questions
1) *Please*, *please*, *please* let's start doing PEP conversations as PRs
to pypa/interoperability-pe
It looks like you would normally be able to say just 'flit' in the
bootstrap-requires or provided-by, unless the requirements were for build
code bundled inside the sdist.
On Tue, Oct 27, 2015 at 1:07 AM Robert Collins
wrote:
> On 27 October 2015 at 14:06, Robert Collins
> wrote:
>
> > We can r
On Tue, Oct 27, 2015 at 1:23 AM, Robert Collins
wrote:
> wheel: flit wheel -d $
>
> OUTPUT_DIR
What's expected to happen if there are multiple files produced in
$OUTPUT_DIR? Is it an error?
Also, doesn't this pep overlap with PEP 426? Shouldn't these ideas be
incorporated there? It seems t
On 27 October 2015 at 14:06, Robert Collins wrote:
> We can rev this in schema version 2. There's no prose in the PEP about
> how that should work, so I'll add that now.
Done: https://gist.github.com/rbtcollins/666c12aec869237f7cf7#upgrades
-Rob
--
Robert Collins
Distinguished Technologist
H
On 27 October 2015 at 13:07, Ionel Cristian Mărieș wrote:
>
> On Tue, Oct 27, 2015 at 1:23 AM, Robert Collins
> wrote:
>>
>> wheel: flit wheel -d $
>> OUTPUT_DIR
>
>
> What's expected to happen if there are multiple files produced in
> $OUTPUT_DIR? Is it an error?
https://github.com/pypa/pip/blo
On 27 October 2015 at 10:32, Ralf Gommers wrote:
>
>
> On Mon, Oct 26, 2015 at 7:01 AM, Robert Collins
> wrote:
>>
>> Since Nathaniel seems busy, I've taken the liberty of drafting a
>> narrow PEP based on the conversations that arose from the prior
>> discussion.
>>
>> It (naturally) has my uniq
On Mon, Oct 26, 2015 at 7:01 AM, Robert Collins
wrote:
> Since Nathaniel seems busy, I've taken the liberty of drafting a
> narrow PEP based on the conversations that arose from the prior
> discussion.
>
> It (naturally) has my unique flavor, but builds on the work Nathaniel
> had put together, s
Since Nathaniel seems busy, I've taken the liberty of drafting a
narrow PEP based on the conversations that arose from the prior
discussion.
It (naturally) has my unique flavor, but builds on the work Nathaniel
had put together, so I've put his name as a co-author even though he
hasn't seen a word
On 26 October 2015 at 19:04, Nathaniel Smith wrote:
> Wow, uh, that's some timing we have. I'll, uh, take a look :-)
Hah! Jinx. Thanks. I'll read through yours too :)
-Rob
--
Robert Collins
Distinguished Technologist
HP Converged Cloud
___
Distutil
Wow, uh, that's some timing we have. I'll, uh, take a look :-)
On Sun, Oct 25, 2015 at 11:01 PM, Robert Collins
wrote:
> Since Nathaniel seems busy, I've taken the liberty of drafting a
> narrow PEP based on the conversations that arose from the prior
> discussion.
>
> It (naturally) has my uniqu
42 matches
Mail list logo
