Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Thu, Apr 25, 2013 at 10:13 AM, Nick Coghlan wrote:
> On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft 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 understands strings like "Donald Stufft
> > (http://github.com/dstufft/)". And both the email
> and url
> > data is optional.
>
> How about the following as the canonical PEP 426 representation:
>
> "contact": {
> "name": "Donald Stufft",
> "email": "don...@stufft.io",
> "url": "http://github.com/dstufft/";
> }
> "contributors": []
>
> The point of the neutral "contact" entry is that it may be a larger entity
> like:
>
> "contact": {
> "name": "Python Packaging Authority",
> "email": "pypa-...@googlegroups.com",
> "url": "http://github.com/pypa";
> }
>
> or the distutils-sig+BitBucket variant of that:
>
>"contact": {
> "name": "Python Packaging Authority/Distutils SIG",
> "email": "distutils-sig@python.org",
> "url": "http://bitbucket.org/pypa";
> }
>
I guess we're still talking about Author field? I don't like the
substitution of author with contact point. For the software catalog people
need to know other packages made by the author, not the packages made by
contact point.
I also don't like the approach to "normalize metadata format" to the 5th
form. What is the goal of the format? Why it is not recorded in PEP 426. If
the goal is to make DB queries - then normalization is ok. If the goal is
to make it readable then we need to make format easier to type. For DB
catalog you will need to parse metadata and build indexes anyway. There is
no need to embed a bomb to kill all rabbits to the meta format.
For further work on this there needs to be a goal. If the goal is to help
people to see who made what and encourage open source collaboration -
that's one thing. If the goal is to make catalog a corporative asset out of
packages and contact points, then it is another. I'd stick with Author and
Contributor semantic for now and add all other stuff later. If further
formalization is needed - there is a common notion of project People and
Roles. IMO it is a better way to go.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
Thread hijacked. -- anatoly t. On Thu, Apr 25, 2013 at 6:01 PM, Donald Stufft wrote: > > On Apr 25, 2013, at 10:47 AM, Nick Coghlan 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 > creates the sdist (and hence pymeta.json) from a source tarball or VCS > checkout (as well as determine the necessary dependencies for that step). > > A minimal file that only requires what's needed for bootstrapping the > archiver is fine. > > My reason for wanting to flesh out a more comprehensive pymeta.cfg spec, > though, is as a sanity check on the proposed PEP 426 metadata. If I can't > come up with a clean multi-file input format, then I will be highly > suspicious of the underlying data model. > > I don't see anything wrong with making this spec but I don't think it > should be conflated with the PEP for a standard way to bootstrap the > archiver. I also don't think it belongs as a PEP as its not a proposal to > enhance python just a test of the new metadata and an example of what an > archiver _could_ use as its format. > > Cheers, > Nick. > > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > > > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > > ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Apr 25, 2013, at 10:47 AM, Nick Coghlan 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 > creates the sdist (and hence pymeta.json) from a source tarball or VCS > checkout (as well as determine the necessary dependencies for that step). > A minimal file that only requires what's needed for bootstrapping the archiver is fine. > My reason for wanting to flesh out a more comprehensive pymeta.cfg spec, > though, is as a sanity check on the proposed PEP 426 metadata. If I can't > come up with a clean multi-file input format, then I will be highly > suspicious of the underlying data model. > I don't see anything wrong with making this spec but I don't think it should be conflated with the PEP for a standard way to bootstrap the archiver. I also don't think it belongs as a PEP as its not a proposal to enhance python just a test of the new metadata and an example of what an archiver _could_ use as its format. > Cheers, > Nick. > > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
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 checkout (as well as determine the necessary dependencies for that step). My reason for wanting to flesh out a more comprehensive pymeta.cfg spec, though, is as a sanity check on the proposed PEP 426 metadata. If I can't come up with a clean multi-file input format, then I will be highly suspicious of the underlying data model. Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On 25 Apr, 2013, at 15:58, Daniel Holth 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 format is done that limits it explicitly to distutils (and possibly setuptools), with the express purpose of making it possible to use a setup.cfg with a minimal setup.py file when using a new enough distutils version. In particular, a python distribution without extensions shouldn't require anything beyond this: from distutils.core import setup setup() This would make it easier to teach (GUI) tools, like IDLE, to maintain the input data used by distutils because they won't have to try to parse and update Python code. Using PEP 390 beyond distutils/setuptools isn't useful, there is no need to restrict other tools in this way as long as they can generate output in the right format (wheel and sdist archives). > > The .ini format and our parsers for it are really awful. I always > resented having to learn it in order to use distutils/setuptools when > every other language (RFC822, Python, JSON) is both better and already > familiar. Funnily, I tend to use ini files a lot at $work because the are good enough for simple configuration and power-users/admins with a windows background are more likely to understand them then json or (shudder) xml files. > > FWIW bdist_wheel does something half-PEP-390 inspired with setup.cfg: > > [metadata] > provides-extra = >tool >signatures >faster-signatures > requires-dist = >distribute (>= 0.6.34) >argparse; python_version == '2.6' >keyring; extra == 'signatures' >dirspec; sys.platform != 'win32' and extra == 'signatures' >ed25519ll; extra == 'faster-signatures' > license-file = LICENSE.txt I use something simular in a number of my packages, with a single setup.py file shared between them and all metadata in setup.cfg. Ronald > > (https://bitbucket.org/dholth/wheel/src/tip/setup.cfg?at=default) > > > On Thu, Apr 25, 2013 at 8:30 AM, Vinay Sajip wrote: >> Nick Coghlan 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 source files and in-package data are >> needed by both builder and archiver. The beauty of JSON is that it allows you >> to have your cake and eat it, to an extent. For example, if you consider that >> inputs to the different roles are dicts, it's not a big deal if you have a >> higher-level dict which contains the others as sub-dicts. So I don't see a >> big issue with having one file as long as the schema is clearly defined so >> that a specific role could pull out the relevant stuff. >> >> Also note that in the PEP 397 implementation (dictConfig) there is already >> the ability to have cross-references to shared sections in a dict serialised >> as JSON, so there's no need to compromise on DRY even when there are data >> overlaps. >> >> I've added some support for dict-based configuration in distlib (a backport >> of the generic configuration stuff from 2.7/3.2 dictConfig, to support 2.6) >> but the use of that's not yet documented. >> >> Regards, >> >> Vinay Sajip >> >> ___ >> Distutils-SIG maillist - Distutils-SIG@python.org >> http://mail.python.org/mailman/listinfo/distutils-sig > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
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 distutils/setuptools when every other language (RFC822, Python, JSON) is both better and already familiar. FWIW bdist_wheel does something half-PEP-390 inspired with setup.cfg: [metadata] provides-extra = tool signatures faster-signatures requires-dist = distribute (>= 0.6.34) argparse; python_version == '2.6' keyring; extra == 'signatures' dirspec; sys.platform != 'win32' and extra == 'signatures' ed25519ll; extra == 'faster-signatures' license-file = LICENSE.txt (https://bitbucket.org/dholth/wheel/src/tip/setup.cfg?at=default) On Thu, Apr 25, 2013 at 8:30 AM, Vinay Sajip wrote: > Nick Coghlan 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 source files and in-package data are > needed by both builder and archiver. The beauty of JSON is that it allows you > to have your cake and eat it, to an extent. For example, if you consider that > inputs to the different roles are dicts, it's not a big deal if you have a > higher-level dict which contains the others as sub-dicts. So I don't see a > big issue with having one file as long as the schema is clearly defined so > that a specific role could pull out the relevant stuff. > > Also note that in the PEP 397 implementation (dictConfig) there is already > the ability to have cross-references to shared sections in a dict serialised > as JSON, so there's no need to compromise on DRY even when there are data > overlaps. > > I've added some support for dict-based configuration in distlib (a backport > of the generic configuration stuff from 2.7/3.2 dictConfig, to support 2.6) > but the use of that's not yet documented. > > Regards, > > Vinay Sajip > > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
Nick Coghlan 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 source files and in-package data are needed by both builder and archiver. The beauty of JSON is that it allows you to have your cake and eat it, to an extent. For example, if you consider that inputs to the different roles are dicts, it's not a big deal if you have a higher-level dict which contains the others as sub-dicts. So I don't see a big issue with having one file as long as the schema is clearly defined so that a specific role could pull out the relevant stuff. Also note that in the PEP 397 implementation (dictConfig) there is already the ability to have cross-references to shared sections in a dict serialised as JSON, so there's no need to compromise on DRY even when there are data overlaps. I've added some support for dict-based configuration in distlib (a backport of the generic configuration stuff from 2.7/3.2 dictConfig, to support 2.6) but the use of that's not yet documented. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Apr 25, 2013, at 3:13 AM, Nick Coghlan wrote:
> On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft 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 understands strings like "Donald Stufft
>> (http://github.com/dstufft/)". And both the email and url
>> data is optional.
>
> How about the following as the canonical PEP 426 representation:
>
>"contact": {
>"name": "Donald Stufft",
>"email": "don...@stufft.io",
>"url": "http://github.com/dstufft/";
>}
>"contributors": []
>
> The point of the neutral "contact" entry is that it may be a larger entity
> like:
>
>"contact": {
>"name": "Python Packaging Authority",
>"email": "pypa-...@googlegroups.com",
>"url": "http://github.com/pypa";
>}
>
> or the distutils-sig+BitBucket variant of that:
>
> "contact": {
>"name": "Python Packaging Authority/Distutils SIG",
>"email": "distutils-sig@python.org",
>"url": "http://bitbucket.org/pypa";
>}
contact instead of author works for me. That's practically how it's implemented
in distutils ATM anyways (Maintainer overrides author and gets sent _as_ the
author).
>
> As I work on the PEP 426 conversion to JSON as the on-disk format, I'm
> also becoming convinced that we'll want at least a draft of the
> replacement for PEP 390 (static input metadata) before I accept the
> metadata 2.0 spec.
>
> The key difference relative to PEP 390 is that the new PEP (for a
> "pymeta.cfg" file) will be solely intended as an *input* format to a
> build tool that populates pymeta.json when creating an sdist or wheel
> file, whereas PEP 390 wanted to use the same format both for the
> human-friendly input *and* as the machine readable interchange format.
> Working on the PEP 426 conversion has confirmed my opinion that
> 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.
I'm not sold on the pymeta.cfg file. Part of the purpose of defining the sdist
format instead of the tool that creates the sdist format is that we allow any
type of "input file" that someone wants to make a tool that does it. Further
more package creation should ideally be moved out of the stdlib and I don't see
much of a point to creating a PEP for a file that should never leave the
developers computer.
>
> Those two PEPs will then define "this is where we want to get to"
> based on everything we've learned from the status quo and from looking
> at other languages. Then the real work begins of figuring out how the
> hell we can actually get there in a reasonable amount of time :)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft 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 understands strings like "Donald Stufft
> (http://github.com/dstufft/)". And both the email and url
> data is optional.
How about the following as the canonical PEP 426 representation:
"contact": {
"name": "Donald Stufft",
"email": "don...@stufft.io",
"url": "http://github.com/dstufft/";
}
"contributors": []
The point of the neutral "contact" entry is that it may be a larger entity like:
"contact": {
"name": "Python Packaging Authority",
"email": "pypa-...@googlegroups.com",
"url": "http://github.com/pypa";
}
or the distutils-sig+BitBucket variant of that:
"contact": {
"name": "Python Packaging Authority/Distutils SIG",
"email": "distutils-sig@python.org",
"url": "http://bitbucket.org/pypa";
}
As I work on the PEP 426 conversion to JSON as the on-disk format, I'm
also becoming convinced that we'll want at least a draft of the
replacement for PEP 390 (static input metadata) before I accept the
metadata 2.0 spec.
The key difference relative to PEP 390 is that the new PEP (for a
"pymeta.cfg" file) will be solely intended as an *input* format to a
build tool that populates pymeta.json when creating an sdist or wheel
file, whereas PEP 390 wanted to use the same format both for the
human-friendly input *and* as the machine readable interchange format.
Working on the PEP 426 conversion has confirmed my opinion that
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.
Those two PEPs will then define "this is where we want to get to"
based on everything we've learned from the status quo and from looking
at other languages. Then the real work begins of figuring out how the
hell we can actually get there in a reasonable amount of time :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Apr 24, 2013, at 11:35 PM, anatoly techtonik wrote:
> To reach the consensus in this discussion, I guess we all agree that roles in
> software projects may differ greatly. Even the 4 user stories listed are not
> enough to give proper credits to all people involved. I guess we can reach
> consensus stating that maintainers of packages in Python world are not common
> - authors or contributors package stuff themselves. PyPI is not Linux
> distribution where package maintainers play a significant and different role.
> So the "author"+ and "contributor"* fields seem to be reasonable minimum core.
>
> Do we all agree on that minimum as the first step?
An author (or authors) and contributors field would be very suitable.
>
> Now about the contents. Only Lennart expressed opinion that separate email
> may be useful because it forces people to supply this email. If emails were
> obligatory, we could consider this point, but my IMO is that this it is not
> an reason to increase complexity of the system.
> http://www.youtube.com/watch?v=rI8tNMsozo0
>
> I like the ability to supply URL in the Author/Contributor field. It can be
> used to link to the project specific way of listing people involved
> (including GitHub pages). But for now I'd not formalize it and considered as
> an optional feature. Just listed somewhere. I'd like not to formalize the
> contents of this field at all leaving the recommendation to supply content in
> "name[ email][, optional stuff]" format. Can we reach a consensus on that?
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 understands strings like "Donald Stufft
(http://github.com/dstufft/)". And both the email and url
data is optional.
> --
> anatoly t.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Wed, Apr 24, 2013 at 6:14 PM, Nick Coghlan wrote:
> On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth wrote:
> > Keep in mind that this is the structured index metadata, which is only
> > used to grab requirements (for end users, who usually don't need the
> > other information at all) and used to generate cheese shop web pages.
> > AUTHORS.txt works when you don't need an automatic "email the author"
> > button. Or the project's github information etc.
> >
> > Someday the JSON version of the metadata will certainly make all these
> > fields a little nicer to parse though. Maybe
> >
> > "authors" : [{'name':'bob', 'email':'b...@example.org'}]
> >
> > The author/maintainer distinction will stay.
>
> FWIW, the current draft of PEP 426 has this note:
>
> .. note:
>
> This section currently mimics the flat layout used in past metadata
> versions. Perhaps it would be better to switch to a different format
> closer to that used for the project URL field::
>
> "contacts": {
> "author": "\"C. Schultz\" "
> "maintainer": "\"P. Patty\" "
> }
>
> So yeah, I'm not particularly happy with the current structure for the
> contact metadata either, but it's a *long* way down my priority list
> of problems to address in the next draft. (My aim to get that posted
> last week proved to be overly optimistic. Because this next update is
> the key-value -> JSON-compatible structured metadata switch, it's hard
> to post a partial update and still have it even vaguely readable)
>
You user story is "contact point". It is quite different from the role of
the author meaning for open source projects. I know at least 5 active open
source projects where people don't like to receive personal email and
prefer to have public tracker or a mailing list as a contact point.
--
anatoly t.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Wed, Apr 24, 2013 at 7:54 PM, Donald Stufft wrote:
>
> On Apr 24, 2013, at 12:42 PM, Donald Stufft wrote:
>
> >
> > On Apr 24, 2013, at 11:14 AM, Nick Coghlan wrote:
> >
> >> On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth
> wrote:
> >>> Keep in mind that this is the structured index metadata, which is only
> >>> used to grab requirements (for end users, who usually don't need the
> >>> other information at all) and used to generate cheese shop web pages.
> >>> AUTHORS.txt works when you don't need an automatic "email the author"
> >>> button. Or the project's github information etc.
> >>>
> >>> Someday the JSON version of the metadata will certainly make all these
> >>> fields a little nicer to parse though. Maybe
> >>>
> >>> "authors" : [{'name':'bob', 'email':'b...@example.org'}]
> >>>
> >>> The author/maintainer distinction will stay.
> >>
> >> FWIW, the current draft of PEP 426 has this note:
> >>
> >> .. note:
> >>
> >> This section currently mimics the flat layout used in past metadata
> >> versions. Perhaps it would be better to switch to a different format
> >> closer to that used for the project URL field::
> >>
> >> "contacts": {
> >> "author": "\"C. Schultz\" "
> >> "maintainer": "\"P. Patty\" "
> >> }
> >>
> >> So yeah, I'm not particularly happy with the current structure for the
> >> contact metadata either, but it's a *long* way down my priority list
> >> of problems to address in the next draft. (My aim to get that posted
> >> last week proved to be overly optimistic. Because this next update is
> >> the key-value -> JSON-compatible structured metadata switch, it's hard
> >> to post a partial update and still have it even vaguely readable)
> >>
> >> Cheers,
> >> Nick.
> >>
> >> --
> >> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
> >> ___
> >> Distutils-SIG maillist - Distutils-SIG@python.org
> >> http://mail.python.org/mailman/listinfo/distutils-sig
> >
> >
> > Looking at other languages they all seem to accept N number of "authors"
> or
> > "contributors". Possibly something like that would be a good to do.
> >
> > -
> > Donald Stufft
> > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
> >
> > ___
> > Distutils-SIG maillist - Distutils-SIG@python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
> To be specific, here's what node.js does
>
> They have an Author field, who represents the primary author of the
> package,
> and then a contributors field that accepts a list of people who have
> contributed
> to the package. NPM will also automatically fill this out if left blank by
> using an
> AUTHORS file assuming the file has 1 per line and each line is in the
> format
> of Name (url).
>
> Ruby has an authors field which is a list of all the authors.
I see it this way. There are four user stories. In all three author field
is an id of:
1. (copyright) software authors (collective team or single-person)
2. (credits) contributors (people who helped)
3. (publishing) package maintainers (people who port stuff to different
systems)
4. (support) software maintainers (contact points)
I guess the good rule is not overengineer the stuff. We can formalize
everything endlessly and will get XHTML in the end. I prefer practical
HTML5 approach where the data is directed by a user story. Every change
needs an existing user who has requirements and data format should cover
this specific user's story without making any speculations and assumptions
about future use.
To reach the consensus in this discussion, I guess we all agree that roles
in software projects may differ greatly. Even the 4 user stories listed are
not enough to give proper credits to all people involved. I guess we can
reach consensus stating that maintainers of packages in Python world are
not common - authors or contributors package stuff themselves. PyPI is not
Linux distribution where package maintainers play a significant and
different role. So the "author"+ and "contributor"* fields seem to be
reasonable minimum core.
Do we all agree on that minimum as the first step?
Now about the contents. Only Lennart expressed opinion that separate email
may be useful because it forces people to supply this email. If emails were
obligatory, we could consider this point, but my IMO is that this it is not
an reason to increase complexity of the system.
http://www.youtube.com/watch?v=rI8tNMsozo0
I like the ability to supply URL in the Author/Contributor field. It can be
used to link to the project specific way of listing people involved
(including GitHub pages). But for now I'd not formalize it and considered
as an optional feature. Just listed somewhere. I'd like not to formalize
the contents of this field at all leaving the recommendation to supply
content in "name[ email][, optional stuff]" format.
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Apr 24, 2013, at 12:42 PM, Donald Stufft wrote:
>
> On Apr 24, 2013, at 11:14 AM, Nick Coghlan wrote:
>
>> On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth wrote:
>>> Keep in mind that this is the structured index metadata, which is only
>>> used to grab requirements (for end users, who usually don't need the
>>> other information at all) and used to generate cheese shop web pages.
>>> AUTHORS.txt works when you don't need an automatic "email the author"
>>> button. Or the project's github information etc.
>>>
>>> Someday the JSON version of the metadata will certainly make all these
>>> fields a little nicer to parse though. Maybe
>>>
>>> "authors" : [{'name':'bob', 'email':'b...@example.org'}]
>>>
>>> The author/maintainer distinction will stay.
>>
>> FWIW, the current draft of PEP 426 has this note:
>>
>> .. note:
>>
>> This section currently mimics the flat layout used in past metadata
>> versions. Perhaps it would be better to switch to a different format
>> closer to that used for the project URL field::
>>
>> "contacts": {
>> "author": "\"C. Schultz\" "
>> "maintainer": "\"P. Patty\" "
>> }
>>
>> So yeah, I'm not particularly happy with the current structure for the
>> contact metadata either, but it's a *long* way down my priority list
>> of problems to address in the next draft. (My aim to get that posted
>> last week proved to be overly optimistic. Because this next update is
>> the key-value -> JSON-compatible structured metadata switch, it's hard
>> to post a partial update and still have it even vaguely readable)
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>> ___
>> Distutils-SIG maillist - Distutils-SIG@python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
>
>
> Looking at other languages they all seem to accept N number of "authors" or
> "contributors". Possibly something like that would be a good to do.
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
> ___
> Distutils-SIG maillist - Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
To be specific, here's what node.js does
They have an Author field, who represents the primary author of the package,
and then a contributors field that accepts a list of people who have contributed
to the package. NPM will also automatically fill this out if left blank by
using an
AUTHORS file assuming the file has 1 per line and each line is in the format
of Name (url).
Ruby has an authors field which is a list of all the authors.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Apr 24, 2013, at 11:14 AM, Nick Coghlan wrote:
> On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth wrote:
>> Keep in mind that this is the structured index metadata, which is only
>> used to grab requirements (for end users, who usually don't need the
>> other information at all) and used to generate cheese shop web pages.
>> AUTHORS.txt works when you don't need an automatic "email the author"
>> button. Or the project's github information etc.
>>
>> Someday the JSON version of the metadata will certainly make all these
>> fields a little nicer to parse though. Maybe
>>
>> "authors" : [{'name':'bob', 'email':'b...@example.org'}]
>>
>> The author/maintainer distinction will stay.
>
> FWIW, the current draft of PEP 426 has this note:
>
> .. note:
>
>This section currently mimics the flat layout used in past metadata
>versions. Perhaps it would be better to switch to a different format
>closer to that used for the project URL field::
>
>"contacts": {
>"author": "\"C. Schultz\" "
>"maintainer": "\"P. Patty\" "
>}
>
> So yeah, I'm not particularly happy with the current structure for the
> contact metadata either, but it's a *long* way down my priority list
> of problems to address in the next draft. (My aim to get that posted
> last week proved to be overly optimistic. Because this next update is
> the key-value -> JSON-compatible structured metadata switch, it's hard
> to post a partial update and still have it even vaguely readable)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
> ___
> Distutils-SIG maillist - Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
Looking at other languages they all seem to accept N number of "authors" or
"contributors". Possibly something like that would be a good to do.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth wrote:
> Keep in mind that this is the structured index metadata, which is only
> used to grab requirements (for end users, who usually don't need the
> other information at all) and used to generate cheese shop web pages.
> AUTHORS.txt works when you don't need an automatic "email the author"
> button. Or the project's github information etc.
>
> Someday the JSON version of the metadata will certainly make all these
> fields a little nicer to parse though. Maybe
>
> "authors" : [{'name':'bob', 'email':'b...@example.org'}]
>
> The author/maintainer distinction will stay.
FWIW, the current draft of PEP 426 has this note:
.. note:
This section currently mimics the flat layout used in past metadata
versions. Perhaps it would be better to switch to a different format
closer to that used for the project URL field::
"contacts": {
"author": "\"C. Schultz\" "
"maintainer": "\"P. Patty\" "
}
So yeah, I'm not particularly happy with the current structure for the
contact metadata either, but it's a *long* way down my priority list
of problems to address in the next draft. (My aim to get that posted
last week proved to be overly optimistic. Because this next update is
the key-value -> JSON-compatible structured metadata switch, it's hard
to post a partial update and still have it even vaguely readable)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
Keep in mind that this is the structured index metadata, which is only
used to grab requirements (for end users, who usually don't need the
other information at all) and used to generate cheese shop web pages.
AUTHORS.txt works when you don't need an automatic "email the author"
button. Or the project's github information etc.
Someday the JSON version of the metadata will certainly make all these
fields a little nicer to parse though. Maybe
"authors" : [{'name':'bob', 'email':'b...@example.org'}]
The author/maintainer distinction will stay.
On Wed, Apr 24, 2013 at 10:06 AM, Lennart Regebro wrote:
> On Wed, Apr 24, 2013 at 11:19 AM, anatoly techtonik
> wrote:
>> Having a lot of meaningless options doesn't make meta data any more clear.
>> Well, they are not meaningless, but their role is fully fulfilled by other
>> options (Author and Maintainer fields in this particular case).
>>
>> The use case for the Author field is that if Author wants to be contacted,
>> (s)he leaves email. That's it. This use case should be described in the
>> meta-data along with the format that are expected to be recognized by the
>> software:
>>
>> Author: anatoly techtonik
>> Author: anatoly techtonik
>> Author: anatoly techtonik , Anything Else for Humans,
>> Or For Future Specs
>>
>> Here the field content defines its type - it's like duck typing for
>> specification, which make specifications more pythonic.
>>
>> Is it good?
>
> Nope. Having a separate field for email makes it clear that you should
> add the email there IMO. However, both author-email and
> maintainer-email are redundant, as is author and maintainer. The
> relevant info is maintainer, to be honest.
>
> //Lennart
> ___
> Distutils-SIG maillist - Distutils-SIG@python.org
> http://mail.python.org/mailman/listinfo/distutils-sig
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Wed, Apr 24, 2013 at 5:06 PM, Lennart Regebro wrote: > On Wed, Apr 24, 2013 at 11:19 AM, anatoly techtonik > wrote: > > Having a lot of meaningless options doesn't make meta data any more > clear. > > Well, they are not meaningless, but their role is fully fulfilled by > other > > options (Author and Maintainer fields in this particular case). > > > > The use case for the Author field is that if Author wants to be > contacted, > > (s)he leaves email. That's it. This use case should be described in the > > meta-data along with the format that are expected to be recognized by the > > software: > > > > Author: anatoly techtonik > > Author: anatoly techtonik > > Author: anatoly techtonik , Anything Else for > Humans, > > Or For Future Specs > > > > Here the field content defines its type - it's like duck typing for > > specification, which make specifications more pythonic. > > > > Is it good? > > Nope. Having a separate field for email makes it clear that you should > add the email there IMO. However, both author-email and > maintainer-email are redundant, as is author and maintainer. The > relevant info is maintainer, to be honest. > > //Lennart > Probably some projects have more than one person handling them. I agree that the author/maintainer distinction isn't interesting. A list of maintainer emails may be a good solution. Not that we can have any semblance of this on pypi, I just wanted to mention this is very nicely done on github e.g. https://github.com/mrdoob/three.js/contributors Yuval Greenfield ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Wed, Apr 24, 2013 at 11:19 AM, anatoly techtonik wrote: > Having a lot of meaningless options doesn't make meta data any more clear. > Well, they are not meaningless, but their role is fully fulfilled by other > options (Author and Maintainer fields in this particular case). > > The use case for the Author field is that if Author wants to be contacted, > (s)he leaves email. That's it. This use case should be described in the > meta-data along with the format that are expected to be recognized by the > software: > > Author: anatoly techtonik > Author: anatoly techtonik > Author: anatoly techtonik , Anything Else for Humans, > Or For Future Specs > > Here the field content defines its type - it's like duck typing for > specification, which make specifications more pythonic. > > Is it good? Nope. Having a separate field for email makes it clear that you should add the email there IMO. However, both author-email and maintainer-email are redundant, as is author and maintainer. The relevant info is maintainer, to be honest. //Lennart ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
Having a lot of meaningless options doesn't make meta data any more clear. Well, they are not meaningless, but their role is fully fulfilled by other options (Author and Maintainer fields in this particular case). The use case for the Author field is that if Author wants to be contacted, (s)he leaves email. That's it. This use case should be described in the meta-data along with the format that are expected to be recognized by the software: Author: anatoly techtonik Author: anatoly techtonik Author: anatoly techtonik , Anything Else for Humans, Or For Future Specs Here the field content defines its type - it's like duck typing for specification, which make specifications more pythonic. Is it good? -- anatoly t. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
