On Thu, Oct 4, 2012 at 5:47 PM, Nick Coghlan wrote:
> On Thu, Oct 4, 2012 at 6:25 PM, Paul Moore wrote:
>> 2. Some level of standardised functionality for building and
>> installing. By "standardised", I mean that given *any* sdist, no
>> matter what build tool it uses under the scenes, there is
On Thu, Oct 4, 2012 at 6:25 PM, Paul Moore wrote:
> 2. Some level of standardised functionality for building and
> installing. By "standardised", I mean that given *any* sdist, no
> matter what build tool it uses under the scenes, there is a way of
> saying "build this, and put the output into the
On Thu, Oct 4, 2012 at 8:55 AM, Paul Moore wrote:
> On 28 September 2012 18:05, Nick Coghlan wrote:
>> On Fri, Sep 28, 2012 at 10:07 AM, Daniel Holth wrote:
>>> Are we trying to kill setuptools? I'm not entirely sure, but we should
>>> stop trying to do that. The migration should take essentiall
On Mon, Oct 1, 2012 at 8:22 PM, Vinay Sajip wrote:
> David Cournapeau gmail.com> writes:
>
>> I noticed that you put the classifiers list as a string (same for
>> platform). I think it is expected to be a list, no ?
>
> That's an oversight; there are doubtless others, too.
Sure. I guess I was ju
On 28 September 2012 18:05, Nick Coghlan wrote:
> On Fri, Sep 28, 2012 at 10:07 AM, Daniel Holth wrote:
>> Are we trying to kill setuptools? I'm not entirely sure, but we should
>> stop trying to do that. The migration should take essentially forever
>> as soon as it makes sense for each pypi pub
David Cournapeau gmail.com> writes:
> I noticed that you put the classifiers list as a string (same for
> platform). I think it is expected to be a list, no ?
That's an oversight; there are doubtless others, too.
> Maybe slightly more controversial, I think the manifest should be
> "evaluated"
On Mon, Oct 1, 2012 at 5:06 PM, Vinay Sajip wrote:
> David Cournapeau gmail.com> writes:
>
>> The code that produces yaml files. The point is precisely that it
>> would be easy for me to consume this and produce the internal package
>> representation in bento, which would then allow to configure,
David Cournapeau gmail.com> writes:
> The code that produces yaml files. The point is precisely that it
> would be easy for me to consume this and produce the internal package
> representation in bento, which would then allow to configure, build
> and install packages using the bento format.
Wel
Yes, and I've added its package.yaml to the original Gist at
https://gist.github.com/3803556
Regards,
Vinay Sajip
>
> From: Daniel Holth
>To: Vinay Sajip
>Sent: Monday, 1 October 2012, 15:27
>Subject: Re: [Distutils] [Python-Dev]
On Mon, Oct 1, 2012 at 3:15 PM, Vinay Sajip wrote:
> David Cournapeau gmail.com> writes:
>
>> Note that in Cabal at least, those conditionals work not just for
>> requirements, but for pretty much any section that is not metadata (so
>> in the python world, you could condition on the package you
David Cournapeau gmail.com> writes:
> Note that in Cabal at least, those conditionals work not just for
> requirements, but for pretty much any section that is not metadata (so
> in the python world, you could condition on the package you want to
> install, etc...).
Right, but the concept of env
On Mon, Oct 1, 2012 at 8:14 AM, Vinay Sajip wrote:
> David Cournapeau gmail.com> writes:
>
>> I am not suggesting something very complicated (we don't want to
>> re-create a language), but more something like cabal (see conditionals
>> in
> http://www.haskell.org/cabal/users-guide/developing-pack
David Cournapeau gmail.com> writes:
> I am not suggesting something very complicated (we don't want to
> re-create a language), but more something like cabal (see conditionals
> in
http://www.haskell.org/cabal/users-guide/developing-packages.html#package-descriptions),
> or even RPM (http://www.r
On Mon, Oct 1, 2012 at 12:40 AM, Donald Stufft wrote:
> On Sunday, September 30, 2012 at 6:50 PM, David Cournapeau wrote:
>
> I am not sure I understand the argument: whatever the syntax, if the
> feature is there, you will have the same problem ? The fact that it is
> used by existing solutions t
On Sun, Sep 30, 2012 at 7:40 PM, Donald Stufft wrote:
> On Sunday, September 30, 2012 at 6:50 PM, David Cournapeau wrote:
>
> I am not sure I understand the argument: whatever the syntax, if the
> feature is there, you will have the same problem ? The fact that it is
> used by existing solutions t
On Sunday, September 30, 2012 at 6:50 PM, David Cournapeau wrote:
> I am not sure I understand the argument: whatever the syntax, if the
> feature is there, you will have the same problem ? The fact that it is
> used by existing solutions tend to convince me it is not a problem
> (cabal works much
On Sun, Sep 30, 2012 at 11:35 PM, Donald Stufft wrote:
> On Sunday, September 30, 2012 at 6:21 PM, David Cournapeau wrote:
>
> Right, in that case, it would work, but in my experience, it is
> important to be able to apply conditionals to more than just
> requirements (packages definition and so o
On Sunday, September 30, 2012 at 6:21 PM, David Cournapeau wrote:
> Right, in that case, it would work, but in my experience, it is
> important to be able to apply conditionals to more than just
> requirements (packages definition and so on).
>
A significant problem is caused by the allowance of i
On Sun, Sep 30, 2012 at 5:07 PM, Donald Stufft wrote:
> On Sunday, September 30, 2012 at 8:59 AM, David Cournapeau wrote:
>
> Note that all this work has already been done in Bento.
>
> I understand the appeal of using an existing format like yaml, but it
> is not clear to me how one can handle co
On Sunday, September 30, 2012 at 12:38 PM, Daniel Holth wrote:
> It's the same. Someone will write a bento conditionals to pep markers
> compiler and it will be trivial.
>
>
Right same concept, the difference being one requires a specialized parser and
the other uses a standard parser availab
It's the same. Someone will write a bento conditionals to pep markers
compiler and it will be trivial.
On Sep 30, 2012 12:07 PM, "Donald Stufft" wrote:
> On Sunday, September 30, 2012 at 8:59 AM, David Cournapeau wrote:
>
> Note that all this work has already been done in Bento.
>
> I understand
On Sunday, September 30, 2012 at 8:59 AM, David Cournapeau wrote:
> Note that all this work has already been done in Bento.
>
> I understand the appeal of using an existing format like yaml, but it
> is not clear to me how one can handle conditional with it, and I think
> you want to handle condit
David Cournapeau gmail.com> writes:
> Note that being able to convert a package does not mean the conversion
> is working. You need to make sure that installing something from this
> new format gives the same thing as installing from the setup.py.
> That's harder to test, obviously.
Right, and I
On Sun, Sep 30, 2012 at 8:59 AM, David Cournapeau wrote:
> On Sun, Sep 30, 2012 at 6:03 AM, Donald Stufft
> wrote:
>> I have some unpublished work I should publish.
>>
>> Part of the point with what i'm trying to do is to define a standard for
>> what is inside
>> a package, but not really for h
On Sun, Sep 30, 2012 at 4:55 AM, Daniel Holth wrote:
> I like this kind of study. Fixing 1300 packages sounds a lot more
> manageable than fixing 18,000. (I took a similar look at setup.py but
> with the ast module instead of actually running the things. Your
> method is probably more accurate.) I
On Sun, Sep 30, 2012 at 6:03 AM, Donald Stufft wrote:
> I have some unpublished work I should publish.
>
> Part of the point with what i'm trying to do is to define a standard for
> what is inside
> a package, but not really for how you take a particular set of files and
> turn it into
> that. So
On Sep 30, 2012, at 2:07 AM, Donald Stufft wrote:
> On Sunday, September 30, 2012 at 1:33 AM, Daniel Holth wrote:
>> Why not just let any line in pkg-info that starts with json/tag name: decode
>> as json.
> Why use a format that requires custom parsing knowledge to create an internal
> Python
On Sunday, September 30, 2012 at 1:33 AM, Daniel Holth wrote:
> Why not just let any line in pkg-info that starts with json/tag name: decode
> as json.
Why use a format that requires custom parsing knowledge to create an internal
Python representation. It cannot even accurately represent all of
Why not just let any line in pkg-info that starts with json/tag name: decode as
json.
On Sep 30, 2012, at 1:03 AM, Donald Stufft wrote:
> I have some unpublished work I should publish.
>
> Part of the point with what i'm trying to do is to define a standard for what
> is inside
> a package, b
I have some unpublished work I should publish.
Part of the point with what i'm trying to do is to define a standard for what
is inside
a package, but not really for how you take a particular set of files and turn
it into
that. So if you want to edit yaml you can have a yaml file and have a pack
I like this kind of study. Fixing 1300 packages sounds a lot more
manageable than fixing 18,000. (I took a similar look at setup.py but
with the ast module instead of actually running the things. Your
method is probably more accurate.) It would be very cool to know how
many packages use if: stateme
Nick Coghlan gmail.com> writes:
> > The document has changed since then,
> >
http://python-notes.boredomandlaziness.org/en/latest/pep_ideas/core_packaging_api.html
I read from your page there that Donald Stufft is working on a JSON-based
metadata format. I've been looking that the same thing -
> I'd certainly like to kill easy_install, and see any popular elements
> of setuptools metadata become officially defined *independently* of
> any given implementation.
I would like to kill distutils without killing setuptools, if that
makes any sense.
I think the most important thing to do is t
On Fri, Sep 28, 2012 at 10:07 AM, Daniel Holth wrote:
> Are we trying to kill setuptools? I'm not entirely sure, but we should
> stop trying to do that. The migration should take essentially forever
> as soon as it makes sense for each pypi publisher.
I'd certainly like to kill easy_install, and
The wheel strategy has just been to implement the peps in setuptools
and in pkg_resources. It is nearly effortless to do so since the PEPs
are so similar to the existing system of eggs. Plus you get to play
with it using 900 * 1.6 ** (year-2005) packages.
Afterwards, with binary packages, you can
On Fri, Sep 28, 2012 at 9:37 AM, Tarek Ziadé wrote:
> On 9/28/12 12:55 AM, Antoine Pitrou wrote:
>>>
>>> Last but not least, distlib is the plan forward endorsed by python-dev,
>>
>> Is it? I haven't seen a PEP or an official decision about that. Just
>> because
>> someone proposed it on a mailing
36 matches
Mail list logo
