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 depend
On 13 Feb 2013 02:50, "PJ Eby" wrote:
>
> On Tue, Feb 12, 2013 at 3:48 AM, Ronald Oussoren
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
On Tue, Feb 12, 2013 at 10:04 AM, Nick Coghlan wrote:
>
> On 13 Feb 2013 00:55, "Ronald Oussoren" wrote:
> >
> >
> > On 12 Feb, 2013, at 14:46, Daniel Holth wrote:
> > >
> > >
> > > I still think it makes more sense to just download distribute and
> wheel when you want to build one, but to each
On Tue, Feb 12, 2013 at 3:48 AM, Ronald Oussoren 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 like:
>
> Extens
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 1.1
On 12 February 2013 14:54, Daniel Holth 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
(distribution.dist.DistributionMetadata) only writes
On Tue, Feb 12, 2013 at 11:13 AM, Ronald Oussoren wrote:
>
> On 12 Feb, 2013, at 16:55, Daniel Holth wrote:
>
> On Tue, Feb 12, 2013 at 10:04 AM, Nick Coghlan wrote:
>
>>
>> On 13 Feb 2013 00:55, "Ronald Oussoren" wrote:
>> >
>> >
>> > On 12 Feb, 2013, at 14:46, Daniel Holth wrote:
>> > >
>> >
On 12 Feb, 2013, at 16:55, Daniel Holth wrote:
> On Tue, Feb 12, 2013 at 10:04 AM, Nick Coghlan wrote:
>
> On 13 Feb 2013 00:55, "Ronald Oussoren" wrote:
> >
> >
> > On 12 Feb, 2013, at 14:46, Daniel Holth wrote:
> > >
> > >
> > > I still think it makes more sense to just download distribute
On 13 Feb 2013 00:55, "Ronald Oussoren" wrote:
>
>
> On 12 Feb, 2013, at 14:46, Daniel Holth 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
On Tue, Feb 12, 2013 at 9:31 AM, Paul Moore wrote:
> On 12 February 2013 12:54, Nick Coghlan 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
On 12 Feb, 2013, at 14:46, Daniel Holth 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 out.
Why th
On 12 February 2013 12:54, Nick Coghlan 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, except that in RP
On 12 February 2013 13:46, Daniel Holth 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 1.2+ to express
On Tue, Feb 12, 2013 at 4:01 AM, Nick Coghlan wrote:
> On Tue, Feb 12, 2013 at 6:48 PM, Ronald Oussoren
> 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
> > i
On Tue, Feb 12, 2013 at 6:25 AM, Paul Moore wrote:
> On 12 February 2013 08:33, Nick Coghlan 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
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 12 February 2013 08:33, Nick Coghlan 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 silence, but
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 non
[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 wrote:
> My overarching ambition is to encourage migration to a model where
> Archivers create sdists from source control, Builders create wheels
> from sdists, and Insta
On Tue, Feb 12, 2013 at 12:48 AM, Ronald Oussoren
wrote:
>
> On 12 Feb, 2013, at 9:33, Nick Coghlan wrote:
>
>> On Tue, Feb 12, 2013 at 6:25 PM, Ronald Oussoren
>> wrote:
PEPs 426 and 427 between them should achieve the first objective,
while the other parts of PEP 426 should get us a
On Tue, Feb 12, 2013 at 6:48 PM, Ronald Oussoren 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 correctly?
>
> Som
On Tue, Feb 12, 2013 at 6:03 PM, Chris Jerdonek
wrote:
> On Mon, Feb 11, 2013 at 11:08 PM, Nick Coghlan 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 Archiv
On 12 Feb, 2013, at 9:33, Nick Coghlan wrote:
> On Tue, Feb 12, 2013 at 6:25 PM, Ronald Oussoren
> 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
On Tue, Feb 12, 2013 at 6:25 PM, Ronald Oussoren 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, pending the introdu
On 12 Feb, 2013, at 8:08, Nick Coghlan 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 Archiver/Builder config
On Tuesday, February 12, 2013 at 3:03 AM, Chris Jerdonek wrote:
> On Mon, Feb 11, 2013 at 11:08 PM, Nick Coghlan (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 Archiver.
> >
> > We
On Mon, Feb 11, 2013 at 11:08 PM, Nick Coghlan 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 it uses PEPs
On Tue, Feb 12, 2013 at 4:10 PM, Marcus Smith wrote:
> On Mon, Feb 11, 2013 at 9:36 PM, Donald Stufft
> wrote:
>> I think the biggest point of contention here is how does a project
>> that doesn't _need_ any of those new fields opt into the stricter
>> version comparisons?
>
> I guess the answer
On Mon, Feb 11, 2013 at 9:36 PM, Donald Stufft wrote:
> 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, "Project
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 ove
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 c
On Mon, Feb 11, 2013 at 8:01 PM, Daniel Holth wrote:
> On Mon, Feb 11, 2013 at 10:18 PM, Daniel Holth wrote:
>
>> On Mon, Feb 11, 2013 at 1:37 PM, Marcus Smith wrote:
>>
>>> >> Projects which wish to use non-compliant version identifiers must
>>> restrict themselves to metadata v1.1
>>>
>>> cur
On Mon, Feb 11, 2013 at 10:18 PM, Daniel Holth wrote:
> On Mon, Feb 11, 2013 at 1:37 PM, Marcus Smith 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?
>> setup
> >> 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
On Mon, Feb 11, 2013 at 1:37 PM, Marcus Smith 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.
> maybe
>> 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 reall
An updated draft of PEP 426 has been posted. Based on the feedback
received on the previous draft, I decided that the PEP needed to
provide substantially more guidance to readers on what the different
components of the versioning scheme *meant*, rather than assuming that
the reader would be able to
37 matches
Mail list logo
