Two examples of what Metadata 1.3 looks like. This is what you get, in
*.dist-info directories, when installing from wheels generated by the
current version of wheel. Large numbers of wheels can be made with the
patched pip pip wheel packagename - builds wheels for the package and
all its
On Mon, Feb 11, 2013 at 11:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
Making
sure the necessary metadata for the build step is provided as part of
the sdist is the responsibility of the Archiver.
We don't really *care* what format the Archiver uses to gather info
from the user, so long as
On Tuesday, February 12, 2013 at 3:03 AM, Chris Jerdonek wrote:
On Mon, Feb 11, 2013 at 11:08 PM, Nick Coghlan ncogh...@gmail.com
(mailto:ncogh...@gmail.com) wrote:
Making
sure the necessary metadata for the build step is provided as part of
the sdist is the responsibility of the
On 12 Feb, 2013, at 8:08, Nick Coghlan ncogh...@gmail.com wrote:
So, to my mind, the next PEP we're missing is actually one for the
*sdist* format itself, including a definition for how the
meta-packaging system should invoke the sdist-wheel build step,
rather than one for the
On Tue, Feb 12, 2013 at 6:25 PM, Ronald Oussoren ronaldousso...@mac.com wrote:
PEPs 426 and 427 between them should achieve the first objective,
while the other parts of PEP 426 should get us a long way towards
achieving the second (with ./setup.py bdist_wheel as the interim
build hook,
On 12 Feb, 2013, at 9:33, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 12, 2013 at 6:25 PM, Ronald Oussoren ronaldousso...@mac.com
wrote:
PEPs 426 and 427 between them should achieve the first objective,
while the other parts of PEP 426 should get us a long way towards
achieving the
On Tue, Feb 12, 2013 at 6:03 PM, Chris Jerdonek
chris.jerdo...@gmail.com wrote:
On Mon, Feb 11, 2013 at 11:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
Making
sure the necessary metadata for the build step is provided as part of
the sdist is the responsibility of the Archiver.
We don't
On Tue, Feb 12, 2013 at 6:48 PM, Ronald Oussoren ronaldousso...@mac.com wrote:
I agree with that. The hook could be one or two new header fields in the
PKG-INFO
file, with a PEP that describes those keys and how the builder is invoked and
what
it is supposed to do. Am I understanding this
On Tue, Feb 12, 2013 at 12:48 AM, Ronald Oussoren
ronaldousso...@mac.com wrote:
On 12 Feb, 2013, at 9:33, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 12, 2013 at 6:25 PM, Ronald Oussoren ronaldousso...@mac.com
wrote:
PEPs 426 and 427 between them should achieve the first objective,
[In this e-mail I'm combining comments to a few of the e-mails in this thread.]
On Mon, Feb 11, 2013 at 11:08 PM, Nick Coghlan ncogh...@gmail.com wrote:
My overarching ambition is to encourage migration to a model where
Archivers create sdists from source control, Builders create wheels
from
Rpm uses fewer requirements tags like Requires: and BuildRequires:
(the vastly common ones) plus other less frequently used like PreReq:
Provides: Conflicts: BuildConflicts: BuildPreReq: etc.
The BuildConflicts: I never seen a user case for it personally, the
Provides: and Conflicts: on
On 12 February 2013 08:33, Nick Coghlan ncogh...@gmail.com wrote:
The missing piece is a standard hook for invoking the builder to
create a wheel. Currently, that would be via ./setup.py bdist_wheel,
but we want to get away from the setup.py format.
I've offered to do this before to resounding
Disclaimer: these are ideas that have been kicking around in my head
for a while, but they're still somewhat half-baked. By the time we get
around to turning them into a PEP, it's entirely possible I will have
changed my mind again about various aspects. There's also the fact
that I'll probably be
On Tue, Feb 12, 2013 at 6:25 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 12 February 2013 08:33, Nick Coghlan ncogh...@gmail.com wrote:
The missing piece is a standard hook for invoking the builder to
create a wheel. Currently, that would be via ./setup.py bdist_wheel,
but we want to get
On Tue, Feb 12, 2013 at 4:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Feb 12, 2013 at 6:48 PM, Ronald Oussoren ronaldousso...@mac.com
wrote:
I agree with that. The hook could be one or two new header fields in
the PKG-INFO
file, with a PEP that describes those keys and how the
On 12 February 2013 13:46, Daniel Holth dho...@gmail.com wrote:
I'm fairly certain you will find that distutils does not support eggs or
.egg-info at all. It does write PKG-INFO 1.1. bdist_wheel (a setuptools
plugin which does support eggs) has always just upgraded that metadata to
version
On 12 February 2013 12:54, Nick Coghlan ncogh...@gmail.com wrote:
I've learned a lot about packaging in the last year and a half, mostly
through learning how to deal with the SRPM/RPM toolchain after
starting with RH. That's actually where I took the
Archiver-Builder-Installer model from,
On 12 Feb, 2013, at 14:46, Daniel Holth dho...@gmail.com wrote:
I still think it makes more sense to just download distribute and wheel when
you want to build one, but to each his own... if you need to create packages
for pypi without being able to install things from it, knock yourself
On Tue, Feb 12, 2013 at 9:31 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 12 February 2013 12:54, Nick Coghlan ncogh...@gmail.com wrote:
I've learned a lot about packaging in the last year and a half, mostly
through learning how to deal with the SRPM/RPM toolchain after
starting with RH.
On 13 Feb 2013 00:55, Ronald Oussoren ronaldousso...@mac.com wrote:
On 12 Feb, 2013, at 14:46, Daniel Holth dho...@gmail.com wrote:
I still think it makes more sense to just download distribute and wheel
when you want to build one, but to each his own... if you need to create
packages for
On 12 Feb, 2013, at 16:55, Daniel Holth dho...@gmail.com wrote:
On Tue, Feb 12, 2013 at 10:04 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 13 Feb 2013 00:55, Ronald Oussoren ronaldousso...@mac.com wrote:
On 12 Feb, 2013, at 14:46, Daniel Holth dho...@gmail.com wrote:
I still
On Tue, Feb 12, 2013 at 11:13 AM, Ronald Oussoren ronaldousso...@mac.comwrote:
On 12 Feb, 2013, at 16:55, Daniel Holth dho...@gmail.com wrote:
On Tue, Feb 12, 2013 at 10:04 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 13 Feb 2013 00:55, Ronald Oussoren ronaldousso...@mac.com wrote:
On 12 February 2013 14:54, Daniel Holth dho...@gmail.com wrote:
Yes you have my permission to put wheel infrastructure in core. Just do a
good job at it :-)
The wheel spec mandates metadata format 1.2 or later in the PKG-INFO
file. At the moment, distutils
Of course it will be updated as part of the integration after the new
metadata is official. I withdraw my objections on the condition that it is
not done hastily. I will also happily lower the minimum metadata version in
wheel if it helps since it doesn't strictly matter.
The real changes from
On Tue, Feb 12, 2013 at 3:48 AM, Ronald Oussoren ronaldousso...@mac.com wrote:
The hook could be one or two new header fields in the PKG-INFO
file, with a PEP that describes those keys and how the builder is invoked and
what
it is supposed to do. Am I understanding this correctly?
Something
On Tue, Feb 12, 2013 at 10:04 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 13 Feb 2013 00:55, Ronald Oussoren ronaldousso...@mac.com wrote:
On 12 Feb, 2013, at 14:46, Daniel Holth dho...@gmail.com wrote:
I still think it makes more sense to just download distribute and
wheel
On 13 Feb 2013 02:50, PJ Eby p...@telecommunity.com wrote:
On Tue, Feb 12, 2013 at 3:48 AM, Ronald Oussoren ronaldousso...@mac.com
wrote:
The hook could be one or two new header fields in the PKG-INFO
file, with a PEP that describes those keys and how the builder is
invoked and what
it is
Projects which wish to use non-compliant version identifiers must
restrict themselves to metadata v1.1
currently, Projects don't have control over this, right?
setuptools/distutils just writes 1.0 or 1.1 metadata, period.
maybe that can be clarified for me and others.
what can a project really
On Mon, Feb 11, 2013 at 1:37 PM, Marcus Smith qwc...@gmail.com wrote:
Projects which wish to use non-compliant version identifiers must
restrict themselves to metadata v1.1
currently, Projects don't have control over this, right?
setuptools/distutils just writes 1.0 or 1.1 metadata, period.
Projects which wish to use non-compliant version identifiers must
restrict themselves to metadata v1.1
currently, Projects don't have control over this, right?
setuptools/distutils just writes 1.0 or 1.1 metadata, period.
maybe that can be clarified for me and others.
what can a project
On Mon, Feb 11, 2013 at 10:18 PM, Daniel Holth dho...@gmail.com wrote:
On Mon, Feb 11, 2013 at 1:37 PM, Marcus Smith qwc...@gmail.com wrote:
Projects which wish to use non-compliant version identifiers must
restrict themselves to metadata v1.1
currently, Projects don't have control over
On Mon, Feb 11, 2013 at 8:01 PM, Daniel Holth dho...@gmail.com wrote:
On Mon, Feb 11, 2013 at 10:18 PM, Daniel Holth dho...@gmail.com wrote:
On Mon, Feb 11, 2013 at 1:37 PM, Marcus Smith qwc...@gmail.com wrote:
Projects which wish to use non-compliant version identifiers must
restrict
Le 11/02/2013 13:37, Marcus Smith a écrit :
Projects which wish to use non-compliant version identifiers must
restrict themselves to metadata v1.1
currently, Projects don't have control over this, right?
setuptools/distutils just writes 1.0 or 1.1 metadata, period.
Yep, but projects can
On Tuesday, February 12, 2013 at 12:13 AM, Éric Araujo wrote:
Le 11/02/2013 13:37, Marcus Smith a écrit :
Projects which wish to use non-compliant version identifiers must
restrict themselves to metadata v1.1
currently, Projects don't have control over this, right?
On Mon, Feb 11, 2013 at 9:36 PM, Donald Stufft donald.stu...@gmail.comwrote:
On Tuesday, February 12, 2013 at 12:13 AM, Éric Araujo wrote:
Le 11/02/2013 13:37, Marcus Smith a écrit :
Projects which wish to use non-compliant version identifiers must
restrict themselves to metadata v1.1
35 matches
Mail list logo