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 don...@stufft.io wrote: 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 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 Thu, Apr 25, 2013 at 10: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 I think the internal
representation
should be), but the tooling understands strings like Donald Stufft
don...@stufft.io (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: [list of individual contact entries]
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
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 understands strings like Donald Stufft
don...@stufft.io (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: [list of individual contact entries]
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 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 I think the internal representation
should be), but the tooling understands strings like Donald Stufft
don...@stufft.io (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: [list of individual contact entries]
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
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 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
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 vinay_sa...@yahoo.co.uk wrote: 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 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
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 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 vinay_sa...@yahoo.co.uk wrote: 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 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 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 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 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] 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 techto...@gmail.com Author: anatoly techtonik techto...@gmail.com, 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
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Wed, Apr 24, 2013 at 11:19 AM, anatoly techtonik techto...@gmail.com 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 techto...@gmail.com Author: anatoly techtonik techto...@gmail.com, 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
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Wed, Apr 24, 2013 at 5:06 PM, Lennart Regebro rege...@gmail.com wrote: On Wed, Apr 24, 2013 at 11:19 AM, anatoly techtonik techto...@gmail.com 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 techto...@gmail.com Author: anatoly techtonik techto...@gmail.com, 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
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 rege...@gmail.com wrote:
On Wed, Apr 24, 2013 at 11:19 AM, anatoly techtonik techto...@gmail.com
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 techto...@gmail.com
Author: anatoly techtonik techto...@gmail.com, 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 Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth dho...@gmail.com 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\ cschu...@example.com
maintainer: \P. Patty\ ppa...@example.com
}
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
On Apr 24, 2013, at 11:14 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth dho...@gmail.com 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\ cschu...@example.com
maintainer: \P. Patty\ ppa...@example.com
}
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 Apr 24, 2013, at 12:42 PM, Donald Stufft don...@stufft.io wrote:
On Apr 24, 2013, at 11:14 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth dho...@gmail.com 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\ cschu...@example.com
maintainer: \P. Patty\ ppa...@example.com
}
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 email (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 Wed, Apr 24, 2013 at 7:54 PM, Donald Stufft don...@stufft.io wrote:
On Apr 24, 2013, at 12:42 PM, Donald Stufft don...@stufft.io wrote:
On Apr 24, 2013, at 11:14 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth dho...@gmail.com
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\ cschu...@example.com
maintainer: \P. Patty\ ppa...@example.com
}
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 email (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. Can we reach a
consensus on that?
--
anatoly t.
___
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Wed, Apr 24, 2013 at 6:14 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth dho...@gmail.com 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\ cschu...@example.com
maintainer: \P. Patty\ ppa...@example.com
}
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 Apr 24, 2013, at 11:35 PM, anatoly techtonik techto...@gmail.com 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
don...@stufft.io (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
