> Step 3 ("what, if anything, should replace the setup.py CLI as the
> build system abstraction?") [...] research/documentation consolidation
> project at this point than it is a design project.
FYI, I've been experimenting with a design approach for a build system in
distil. Currently it only co
On 24 Mar 2014 10:01, "Paul Moore" wrote:
>
> On 23 March 2014 23:13, Nick Coghlan wrote:
> > Now you begin to see the scope of the problem. It's definitely
solvable, but
> > means asking a whole pile of "required, recommended or
distutils-specific?"
> > questions about the existing distutils and
On 23 March 2014 23:13, Nick Coghlan wrote:
> Now you begin to see the scope of the problem. It's definitely solvable, but
> means asking a whole pile of "required, recommended or distutils-specific?"
> questions about the existing distutils and setuptools build system :)
>
> "pip already relies o
On 24 Mar 2014 00:13, "Paul Moore" wrote:
>
> On 23 March 2014 00:00, Nick Coghlan wrote:
> > On 23 Mar 2014 09:35, "Paul Moore" wrote:
> >>
> >> On 22 March 2014 22:37, Vinay Sajip wrote:
> >> >> 1. Formally decouple the setup.py CLI from the distutils command
system
> >> >
> >> > Agreed - it
On 23 March 2014 00:00, Nick Coghlan wrote:
> On 23 Mar 2014 09:35, "Paul Moore" wrote:
>>
>> On 22 March 2014 22:37, Vinay Sajip wrote:
>> >> 1. Formally decouple the setup.py CLI from the distutils command system
>> >
>> > Agreed - it looks like a compatible CLI needs to be part of the
>> > tr
On 23 Mar 2014 09:35, "Paul Moore" wrote:
>
> On 22 March 2014 22:37, Vinay Sajip wrote:
> >> 1. Formally decouple the setup.py CLI from the distutils command system
> >
> > Agreed - it looks like a compatible CLI needs to be part of the
transition
> > to any new system (I assume that's what you
On 22 March 2014 22:37, Vinay Sajip wrote:
>> 1. Formally decouple the setup.py CLI from the distutils command system
>
> Agreed - it looks like a compatible CLI needs to be part of the transition
> to any new system (I assume that's what you meant).
Does this statement mean "document the exact s
On 23 March 2014 08:37, Vinay Sajip wrote:
>> 1. Formally decouple the setup.py CLI from the distutils command system
>
> Agreed - it looks like a compatible CLI needs to be part of the transition
> to any new system (I assume that's what you meant).
Yeah - we have precedent there with distutils2
> 1. Formally decouple the setup.py CLI from the distutils command system
Agreed - it looks like a compatible CLI needs to be part of the transition
to any new system (I assume that's what you meant).
Regards,
Vinay Sajip
___
Distutils-SIG maillist
I don't think there is a need to be that pessimistic. Most people will even
be able to keep setup.py as is. But when you really should be sidestepping
DistUtils instead of writing a 10k line extension there is a supported path.
On Mar 21, 2014 7:37 PM, "Vinay Sajip" wrote:
>
>
> > This strategy d
On 22 March 2014 09:37, Vinay Sajip wrote:
>> This strategy does not generally try to eliminate arbitrary code
>> execution during builds - builds are an inherently arbitrary-code
>> process. But once the build has happened most installs should work
>> without arbitrary code execution.
>
> I don't
> This strategy does not generally try to eliminate arbitrary code
> execution during builds - builds are an inherently arbitrary-code
> process. But once the build has happened most installs should work
> without arbitrary code execution.
I don't think builds should be a *completely* arbitrary
On Fri, Mar 21, 2014 at 1:46 PM, Daniel Holth wrote:
> Bento emulates setup.py:
> https://github.com/cournape/Bento/blob/master/setup.py
>
> It mostly has to implement egg_info and install to be pip compatible.
>
Yes. While some things are quite not ideal in Bento, I think that part is a
good on
On Mar 21, 2014, at 2:50 PM, Tres Seaver wrote:
> Signed PGP part
> On 03/21/2014 02:37 PM, Paul Moore wrote:
> > Again, though, that's only needed for "pip wheel" or for the
> > install-direct-from-source cases that may not even be expected to
> > work in the new metabuild system...
>
> Hmm, t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/21/2014 02:37 PM, Paul Moore wrote:
> Again, though, that's only needed for "pip wheel" or for the
> install-direct-from-source cases that may not even be expected to
> work in the new metabuild system...
Hmm, that is a clear case of baby-with-
On Fri, Mar 21, 2014 at 2:37 PM, Paul Moore wrote:
> On 21 March 2014 17:56, Daniel Holth wrote:
>> You do need to keep a mechanism to indicate & install build dependencies.
>
> Do we have that at the moment? Metadata 2.0 covers that with
> build_requires. At the moment setup_requires covers it,
On 21 March 2014 17:56, Daniel Holth wrote:
> You do need to keep a mechanism to indicate & install build dependencies.
Do we have that at the moment? Metadata 2.0 covers that with
build_requires. At the moment setup_requires covers it, but I don't
know if/how that works (AIUI, setup_requires is
On Fri, Mar 21, 2014 at 10:25 AM, Paul Moore wrote:
> On 21 March 2014 13:46, Daniel Holth wrote:
>> It mostly has to implement egg_info and install to be pip compatible.
>
> At a *very* brief scan, pip uses just the following setup.py
> invocations (this definitely needs to be properly audited b
On Fri, Mar 21, 2014 at 10:25 AM, Paul Moore wrote:
> On 21 March 2014 13:46, Daniel Holth wrote:
>> It mostly has to implement egg_info and install to be pip compatible.
>
> At a *very* brief scan, pip uses just the following setup.py
> invocations (this definitely needs to be properly audited b
On 21 March 2014 13:46, Daniel Holth wrote:
> It mostly has to implement egg_info and install to be pip compatible.
At a *very* brief scan, pip uses just the following setup.py
invocations (this definitely needs to be properly audited before
relying on it):
For installation from sdist
* setup.py
Bento emulates setup.py: https://github.com/cournape/Bento/blob/master/setup.py
It mostly has to implement egg_info and install to be pip compatible.
In the future we'd like them to implement dist_info (generate a
.dist-info directory instead of an .egg-info directory) and wheel; an
sdist would s
On 20 Mar 2014 23:16, "Brett Cannon" wrote:
>
>
>
> On Thu Mar 20 2014 at 12:51:13 AM, Nick Coghlan
wrote:
>>
>> On 20 March 2014 09:54, Vinay Sajip wrote:
>> > Daniel Holth gmail.com> writes:
>> >
>> >> extensions without using distutils. The problem of invoking the
>> >> compiler has been sol
On Thu Mar 20 2014 at 12:51:13 AM, Nick Coghlan wrote:
> On 20 March 2014 09:54, Vinay Sajip wrote:
> > Daniel Holth gmail.com> writes:
> >
> >> extensions without using distutils. The problem of invoking the
> >> compiler has been solved by many build systems and is not just a
> >> unique and
On 20 March 2014 09:54, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
>> extensions without using distutils. The problem of invoking the
>> compiler has been solved by many build systems and is not just a
>> unique and mysterious distutils feature.
>
> Did someone say it was? Building ex
Daniel Holth gmail.com> writes:
> extensions without using distutils. The problem of invoking the
> compiler has been solved by many build systems and is not just a
> unique and mysterious distutils feature.
Did someone say it was? Building extensions is something distil does too, and
without u
The idea is not new. Here are some examples for SCons:
https://stackoverflow.com/questions/2627731/using-scons-as-a-build-engine-for-distutils
The answers may need to be updated, so if anybody comes
up with convenient distutils tool semantics - it can be
integrated into next SCons release.
On Wed,
26 matches
Mail list logo
