On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft don...@stufft.io wrote:
I like how Node.js packages handled this. The canonical form is {name:
Donald Stufft, email: don...@stufft.io, url:
http://github.com/dstufft/} (and what I think the internal representation
should be), but the tooling
On Apr 25, 2013, at 3:13 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft don...@stufft.io wrote:
I like how Node.js packages handled this. The canonical form is {name:
Donald Stufft, email: don...@stufft.io, url:
http://github.com/dstufft/} (and what
Thanks everybody for your feedback!
On Wed, Apr 24, 2013 at 5:31 PM, Nick Coghlan ncogh...@gmail.com wrote:
That's not a bad summary, and
http://www.scotttorborg.com/python-packaging/index.html looks like an
excellent resource.
I'm going to write him an email pointing him to this thread.
Okay, Gmane subscription requests sent with those names.
If there's consensus to create the new list at some point,
consider adding it to Gmane as well (I'll have forgotten by then,
but it's good to make sure early messages are all archived).
not sure about gmane naming, but my first reaction
Nick Coghlan ncoghlan at gmail.com writes:
splitting them is the right way to go, and also that a multi-file
input format is likely a better option than trying to cram everything
into one file.
There are areas of overlap, if you consider archiver, builder and
installer roles. For example, the
I would prefer to see PEP 390 withdrawn and I think this has been
suggested before. The metadata is already sourced from different files
depending on your build system.
The .ini format and our parsers for it are really awful. I always
resented having to learn it in order to use
On 25 Apr, 2013, at 15:58, Daniel Holth dho...@gmail.com wrote:
I would prefer to see PEP 390 withdrawn and I think this has been
suggested before. The metadata is already sourced from different files
depending on your build system.
I wouldn't mind a PEP 390 update when the 2.0 metadata
The latest pip supports HTTPS URLs and certificate checks
(according to the change log).
Will there be a release of distribute that implements the
same changes ?
The current 0.6.36 still defaults to the HTTP PyPI address
and doesn't do certificate checks.
--
Marc-Andre Lemburg
eGenix.com
I plan to reject PEP 390, since that feature won't be added to the stdlib.
The reason we will need at least a minimal replacement for it is so that
there's a standard place to define and retrieve the archiver hook that
creates the sdist (and hence pymeta.json) from a source tarball or VCS
On Apr 25, 2013, at 10:47 AM, Nick Coghlan ncogh...@gmail.com wrote:
I plan to reject PEP 390, since that feature won't be added to the stdlib.
The reason we will need at least a minimal replacement for it is so that
there's a standard place to define and retrieve the archiver hook that
On Thu, Apr 25, 2013 at 4:42 PM, M.-A. Lemburg m...@egenix.com wrote:
The latest pip supports HTTPS URLs and certificate checks
(according to the change log).
Will there be a release of distribute that implements the
same changes ?
And FWIW, the same question would be relevant for buildout
I was just fiddling with an experimental environment marker
implementation for setuptools, and ran across a bit of a quirk in the
spec. It says that the value of 'extra' is 'None', but that
comparisons can only be done on strings.
This leads to two problems: first, the syntax doesn't have a way
On Fri, Apr 26, 2013 at 10:12 AM, PJ Eby p...@telecommunity.com wrote:
I was just fiddling with an experimental environment marker
implementation for setuptools, and ran across a bit of a quirk in the
spec. It says that the value of 'extra' is 'None', but that
comparisons can only be done on
On Thu, Apr 25, 2013 at 8:12 PM, PJ Eby p...@telecommunity.com wrote:
I was just fiddling with an experimental environment marker
implementation for setuptools, and ran across a bit of a quirk in the
spec. It says that the value of 'extra' is 'None', but that
comparisons can only be done on
On Fri, Apr 26, 2013 at 11:56 AM, Daniel Holth dho...@gmail.com wrote:
requires : [ { condition : foo == 'gurgle', requirements : [ bar,
baz ] } , { requirements : [ quux, splort ] } ]
for a conditional and unconditional requirement.
This syntax would also avoid putting data in keys which
15 matches
Mail list logo
