Issue6992
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2009-09-25 15:03 by techtonik, last changed 2022-04-11 14:56 by admin. This issue is now closed.
Messages (35) | |||
---|---|---|---|
msg93105 - (view) | Author: anatoly techtonik (techtonik) | Date: 2009-09-25 15:03 | |
setup.py should allow to specify multiple authors in package description. |
|||
msg93194 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-28 07:54 | |
You can add them in the author field, separated by a space. It's a free field |
|||
msg93203 - (view) | Author: anatoly techtonik (techtonik) | Date: 2009-09-28 10:32 | |
I want to add their emails also. What to write in author_email in this case? Will such author be parsed by various tools? By PyPi, for example, so that everyone get equal credits. I haven't found any remarks about correct handling of this field in distutils notes. |
|||
msg93204 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-28 10:56 | |
Right, it's not handy for the emails. PyPI will display the author field, followed by the author_email field. So everyone will be displayed but not properly. But no tool is handling the Author and Author-email fields as multi-value fields. Maybe we could extend the Metadata by adding a multi-valued "Contributor" field, that would be composed of a name, and email and a role. In the Metadata file, things would look like this: {{{ Contributor: Tarek,tarek@ziade.org,author Contributor: anatoly techtonik,some@mail.org,maintainer Contributor: John Doe,some@mail.org }}} Where the third field is optional (default: "contributor"). and can be set to "author", "maintainer" or "contributor". On setup.py this would be a 'contributors' list: {{{ setup( contributors=[ ['Tarek', 'tarek@ziade.org', 'author'], ['anatoly techtonik', 'some@mail.org', 'maintainer'], ['John Doe', 'some@mail.org'], ] ) }}} Then, 'author' and 'maintainer' would be deprecated, but still filled by Distutils by choosing some entries out of the contributors list. this would be added in 2.7, 3.2 and PyPI would have to change accordingly. |
|||
msg93217 - (view) | Author: anatoly techtonik (techtonik) | Date: 2009-09-28 16:49 | |
Too complicated. I think any who significantly contributed to some package is an author. Maintainer is the one who does the goodness of making this package available to other systems through PyPi. {{{ authors = [ 'Anatoli <email@here>', 'Tarek <email@here>' ] }}} <email@xxx> part is optional. Simple, intuitive, readable and easy enough to parse. The same for maintainers. There is no need for complicated role management - let's leave this for extensions. At the moment the real problem is to give attribution to several people at once in Pythonic way. =) |
|||
msg93219 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-28 17:02 | |
Notice that there's another issue: maintainer is not written in the Metadata if author is provided. Plus, PyPI has its own role system: owner+maintainer, that has nothing to do with the package Metadata (it's just who registered the package and who was granted some access) So at the end, if we don't manage roles at the Metadata level, I don't see any good reason not to have one single 'authors' option with a list of authors. Having the mail like you've described is a good idea too. |
|||
msg93234 - (view) | Author: anatoly techtonik (techtonik) | Date: 2009-09-28 21:00 | |
Having single `authors` field is enough, indeed. |
|||
msg93284 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2009-09-29 12:16 | |
The good pratice, if there are several authors, is to setup a mailing-list (and put its address as official contact address). Otherwise collaboration gets inevitably messy, since authors can get contacted in private randomly. I don't think we should multiply those fields in order to accomodate for subtle role differences. Also, I don't think PyPI is the place to record detailed attribution information. An ad-hoc CREDITS, ACKS file or similar is what you want IMO. |
|||
msg93285 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-29 13:09 | |
What you are saying is that a project should have one and only one contact email. What Anatoly says is that a project should be able to have several authors. What about having a "Contact-email" then that would replace the "Author-email" field, and an "Author" multi-valued field as described previously. Having an extra email in each Author field would be allowed but not parsed. Each Author field would be a free string that can be "Name", "Firstname Lastname", "Firstname Lastname <email>" or whatever. |
|||
msg93286 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2009-09-29 13:18 | |
> What about having a "Contact-email" then that would replace the > "Author-email" field, and an "Author" multi-valued field as described > previously. Why do we have to add new fields and deprecate others? Just for the sake of confusing users and breaking existing packages? What do we gain exactly? There are enough fields available to make the writing of a setup.py burdensome... If you have several authors, you can separate them with commas in the author field and even include e-mail addresses if you want (e.g. "Tarek Ziadé <tarek@example.com>, Antoine Pitrou <antoine@example.net>"). Not every wish for a new "feature" should be satisfied, IMO. Besides, making metadata complex and version-dependent is the best way to make it useless. |
|||
msg93287 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-29 13:28 | |
The metadata are completely messy. Users are already confused. For instance, since the metadata fields are not fully corresponding to the argument names you can pass into setup.py, you can have an "author" and a "maintainer" argument and Distutils will put only the author one in the metadata field "Author". To fill the "Home-url" metadata, the argument is called "url". The "Summary" metadata is filled with the... "description" argument The "Description" metadata is filled with the... "long_description" argument. So what we would gain is more clarity (as already discussed in other issues) We are already discussing the addition of new fields in PEP 341 for package dependencies, and making others clearer. Replacing the author/author_email/maintainer/maintainer_email mess with a single authors argument, that fills a multi-valued "Author" metadata field make it clearer. Same thing goes with the email issue. |
|||
msg93288 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2009-09-29 13:31 | |
> Replacing the author/author_email/maintainer/maintainer_email mess with > a single authors argument, that fills a multi-valued "Author" metadata > field make it clearer. What does changing the type of the "author" field make clearer exactly? It is a field for human beings to read, and a human being is perfectly able to parse "AP <ap@example.com>, Tarek <tarek@example.com>" without the help of a computer. While there may be some things to clear up in the current metadata, this shouldn't be a pretext to gratuitously change things that are ok. I'm bothered that many people currently seem to think that it's ok to break compatibility for whatever non-critical reason. This is not the way we will make Python a reliable platform to use and develop for. |
|||
msg93289 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-29 13:44 | |
> What does changing the type of the "author" field make clearer exactly? It "Author" not "Authors", that's the difference. Like we have "Classifiers" and not "Classifier". Plus, I am not breaking any compatibility here. A multi-value field in the metadata in Distutils just means that you might find several lines starting with {{{ Author: }}} And that Distutils will be able to recognized both forms, exactly like it does with Metadata v1.0 and metadata v1.1. > I'm bothered that many people currently seem to think that it's ok > to compatibility for whatever non-critical reason. This is not > the way we will make Python a reliable platform to use and develop for. I don't know who you are reffering to, but if you look carefully at the work I've been doing in Distutils, I have never and I will never do any gratuitously change whatsoever. I am bothered that more and more are people constantly jumping on my back everytime I try to make Distutils evolves a bit or everytime I discuss some feature proposals with the community. Any change to the metadata fields will require a PEP 341 change, so everyone will be free to do a +1 or a -1. But saying that making the metadata evolve "is not the way we will make Python a reliable platform to use and develop for" is completely wrong imho. |
|||
msg93290 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2009-09-29 13:50 | |
Most of the meta data is parsed by humans, so I don't see any complication with adding multiple authors to the author field using standard email format: "Anatoli <email@here>, Tarek <email@here>". We already have authors and maintainers (which causes confusion), so adding yet another field for contributors is overkill, IMHO. It's common practice to put credits into a README or separate file within the package. I don't think we should grow the package meta-data beyond what's reasonably needed to identify a package and its origin - otherwise we'll end up with a reinvention of RDF. I'd close this ticket as "works for me". |
|||
msg93291 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2009-09-29 13:54 | |
> I am bothered that more and more are people constantly jumping on my > back everytime I try to make Distutils evolves a bit or everytime I > discuss some feature proposals with the community. This is not "jumping on your back", this is being skeptical about a detail that doesn't seem to warrant a change. It is still unknown what use case the new "author" scheme would solve that the old one doesn't (does someone want the "author" field to be machine parsable? for what purpose?), and this bug report itself is quite nebulous (it is unsure what "doesn't work" since you can put human-readable info about multiple authors in a single unicode string). That's why I call it "gratuitous". > But saying that making the metadata evolve "is not the way we will make > Python a reliable platform to use and develop for" is completely > wrong imho. A metadata system, by definition, has to remain reasonably stable (or be version-numbered, such that old metadata can be recognized properly). You can certainly add fields, but replacing existing fields with others should be sufficiently motivated. If the ID3 spec was rewritten every five years so that you couldn't read back the author info from the MP3s you made in 2000, you wouldn't be very happy :) |
|||
msg93292 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-29 14:09 | |
> We already have authors and maintainers (which causes confusion), > adding yet another field for contributors is overkill, Not on the Metadata side though. That's only on setup() side. The resulting metadata only contains "Author" and "Author-email", and it's calculated using 'author' *or* 'maintainer' arguments. Meaning that when you fill both, one is lost. (and leading to the current inconsistency). So being able to have several Authors (not yet another field, an existing one, but multi-valued) and an "authors" argument would fix this inconsistency since we would be able to keep both. This is not a big change on the metadata format, it just means that we can have extra "Author:" lines, so it's backward compatible. OTHO, deprecating "maintainer" and "maintainer_email" on setup() side, and making it clear that there's only one Author and one email could work too. |
|||
msg93293 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2009-09-29 14:24 | |
Tarek Ziadé wrote: > > Tarek Ziadé <ziade.tarek@gmail.com> added the comment: > >> We already have authors and maintainers (which causes confusion), >> adding yet another field for contributors is overkill, > > Not on the Metadata side though. That's only on setup() side. The > resulting metadata only contains "Author" and "Author-email", and it's > calculated using 'author' *or* 'maintainer' arguments. Meaning that when > you fill both, one is lost. (and leading to the current inconsistency). > > So being able to have several Authors (not yet another field, an > existing one, but multi-valued) and an "authors" argument would fix this > inconsistency since we would be able to keep both. > > This is not a big change on the metadata format, it just means that we > can have extra "Author:" lines, so it's backward compatible. > > OTHO, deprecating "maintainer" and "maintainer_email" on setup() side, > and making it clear that there's only one Author and one email could > work too. In order to clear up the inconsistency with maintainer not being a possible meta-data field, I think "Maintainer" should be added to the meta-data. Dito for "Maintainer-EMail". Regarding making the meta-data fields multi-valued, you have to be aware that when parsing the meta-data using an rfc822 style module, code assuming that only one Author field exists, will return (just) one of the available fields and it's not at all clear which. I still believe that we're better off with a single Author field using comma delimited names, e-mail addresses, etc. Adding "authors" as new keyword argument to setup() isn't going to make things more consistent, only more complex code-wise, so I don't think it's worth the trouble. |
|||
msg93294 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-29 14:28 | |
> A metadata system, by definition, has to remain reasonably stable > (or be version-numbered, such that old metadata can be recognized properly). That's already the case. We have 1.0 and 1.1. 1.1 is used if you add fields like "obsoletes". > You can certainly add fields, but replacing existing fields with > others should be sufficiently motivated. Yes, that why the proposed change is backward compatible: it doesn't replace "Author" but turn it into a multi-valued field like "Classifier". Either you have one author line, and the metadata is 1.0 or 1.1, Either you have several authors, and the metadata is 1.2 and doesn't modify Author but add more of those lines. |
|||
msg93296 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-29 14:45 | |
> In order to clear up the inconsistency with maintainer > not being a possible meta-data field, I think "Maintainer" > should be added to the meta-data. Dito for "Maintainer-EMail". Do you remember what's the story behind those two fields ? I am not sure about the community usage of those since they are competng with author and author_email on setup() side |
|||
msg93297 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2009-09-29 14:56 | |
Tarek Ziadé wrote: > > Tarek Ziadé <ziade.tarek@gmail.com> added the comment: > >> In order to clear up the inconsistency with maintainer >> not being a possible meta-data field, I think "Maintainer" >> should be added to the meta-data. Dito for "Maintainer-EMail". > > Do you remember what's the story behind those two fields ? I don't really remember, but suppose that the field was added for cases where a package is being abandoned by the original author and then maintained by someone new. IMHO, the maintainer could have just added the new contact details to the author field and a mention of the changed maintenance to the description. > I am not sure about the community usage of those since they are competng > with author and author_email on setup() side PyPI just shows the "Author" field, so if a package has different author and maintainer entries, the author field is what's displayed - not exactly useful, since bug reports and the like should normally go to the maintainer, not the author. Adding the maintainer field as well would resolve the issue. |
|||
msg93356 - (view) | Author: anatoly techtonik (techtonik) | Date: 2009-09-30 11:26 | |
> The good pratice, if there are several authors, is to setup a > mailing-list (and put its address as official contact address). True. Some packages already do this. > Otherwise collaboration gets inevitably messy, since authors can get > contacted in private randomly. People who use Python are usually smart enough to include all authors in TO or CC field. > I don't think we should multiply those fields in order to accomodate for > subtle role differences. Also, I don't think PyPI is the place to record > detailed attribution information. An ad-hoc CREDITS, ACKS file or > similar is what you want IMO. Well, I am writing a plugin and I my framework doesn't parse CREDITS, ACKS or similar PEP, but it can extract package information to display my name. I want my name to be displayed by this framework. It is called Trac. > What does changing the type of the "author" field make clearer exactly? > It is a field for human beings to read, and a human being is perfectly > able to parse "AP <ap@example.com>, Tarek <tarek@example.com>" without > the help of a computer. Type of `author` is not changed. It remains a single string that doesn't include email. New field `authors` is introduced instead. It can contain a single string with comma-separated authors. It is even better than list. > The metadata are completely messy. Users are already confused. I think it should go into another `parent` ticket with a title like "Perfection is achieved when there is nothing left to take away". =) I think that we need to deprecate fields and leave links on their meaning and how to translate them into other fields in documentation. After three years everybody (well, at least the major part) will be happy. Otherwise the frustration continue. > Any change to the metadata fields will require a PEP 341 change, so > everyone will be free to do a +1 or a -1. > > But saying that making the metadata evolve "is not the way we will make > Python a reliable platform to use and develop for" is completely > wrong imho. +1 > Most of the meta data is parsed by humans, so I don't see any > complication with adding multiple authors to the author field using > standard email format: "Anatoli <email@here>, Tarek <email@here>". Right, but then what author_email field is for? It looks almost obvious that if author contain list of author names then author_email should contain list of emails. Especially, when you add another author to the package where author_email is already used. We should not forget that developers who are overwhelmed with docs even without distutils and try to keep rules short and simple. > A metadata system, by definition, has to remain reasonably stable (or be > version-numbered, such that old metadata can be recognized properly). > You can certainly add fields, but replacing existing fields with others > should be sufficiently motivated. That's why it should be new `authors` field. > In order to clear up the inconsistency with maintainer not > being a possible meta-data field, I think "Maintainer" should > be added to the meta-data. Dito for "Maintainer-EMail". > > Regarding making the meta-data fields multi-valued, you have > to be aware that when parsing the meta-data using an rfc822 > style module, code assuming that only one Author field > exists, will return (just) one of the available fields and > it's not at all clear which. This quote is totally confusing. Sounds WAY too complicated. If you're going to switch to meta-discussions I may fall off at some point. I suspect that there are some meta-internals of Distutils that I must be aware of as a Python developer, but I just want to add myself to setup.py along with other developer and learn my framework use this info fully. Consider this a user-story. >>> In order to clear up the inconsistency with maintainer >>> not being a possible meta-data field, I think "Maintainer" >>> should be added to the meta-data. Dito for "Maintainer-EMail". >> >> Do you remember what's the story behind those two fields ? > > I don't really remember, but suppose that the field was > added for cases where a package is being abandoned by the > original author and then maintained by someone new. I thought that setup.py metadata format is extensible. Let's leave `maintainers` extension to the tools that need it, i.e. PyPI. But IIRC even PyPI doesn't use this field to grant access to package info. |
|||
msg93357 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2009-09-30 11:50 | |
anatoly techtonik wrote: >> What does changing the type of the "author" field make clearer exactly? >> It is a field for human beings to read, and a human being is perfectly >> able to parse "AP <ap@example.com>, Tarek <tarek@example.com>" without >> the help of a computer. > > Type of `author` is not changed. It remains a single string that > doesn't include email. New field `authors` is introduced instead. It > can contain a single string with comma-separated authors. It is even > better than list. Right, but then we have: author author_email authors maintainer maintainer_email for consitency, we'd also need: author_emails maintainers maintainer_emails That's even more confusing than what we already have and it's not needed to solve the use case. >> Most of the meta data is parsed by humans, so I don't see any >> complication with adding multiple authors to the author field using >> standard email format: "Anatoli <email@here>, Tarek <email@here>". > > Right, but then what author_email field is for? No idea. I think it was a YAGNI which was not really needed. >> In order to clear up the inconsistency with maintainer not >> being a possible meta-data field, I think "Maintainer" should >> be added to the meta-data. Dito for "Maintainer-EMail". >> >> Regarding making the meta-data fields multi-valued, you have >> to be aware that when parsing the meta-data using an rfc822 >> style module, code assuming that only one Author field >> exists, will return (just) one of the available fields and >> it's not at all clear which. > > This quote is totally confusing. Sounds WAY too complicated. If you're > going to switch to meta-discussions I may fall off at some point. The first part of the quote should be clear. We need a new meta-field for the already existing setup() keyword parameters maintainer and maintainer_email. The second part is something to consider when switching from a single value meta-data field to a multi-valued one. The meta-data file in distutils uses the RFC 822 header format and the rfc822 (in Python 2.x) provides easy ways of getting at those headers. However, if code assumes that there's only one "Author" header, it will just see the last occurrence of that header in the file. In summary, all that needs to be done is: * adding the maintainer headers to the meta-data format * documenting that multiple authors should use a comma-separated list of names (optionally with email addresses) in the author field. * document that the author_email and maintainer_email addresses should be used to provide a main contact email address for each (e.g. the address of a mailing list) |
|||
msg93358 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-30 12:11 | |
> Right, but then we have: > > author > author_email > authors > maintainer > maintainer_email > > for consitency, we'd also need: > > author_emails > maintainers > maintainer_emails In my mind the "perfect" situation would be just two arguments: - authors (goes in Author field - possibly multi-valued) - contact_email (goes in Contact-email field) And deprecate the others. The "maintainer" concept is not on the metadata side, so it's not used at *all* by the third-party tools or by PyPI. Adding it in the metadata adds more confusion imho than deprecate its usage on Distutils side to stick with a very simple concept: - a distribution has authors - a distribution has a contact email. So I am -1 adding Maintainer/Maintainer-email in the Metadata. Now for the "Contact-email", it guess it's OK to keep "author_email -> Author-email", and it's no big deal is "Author" stays singled valued, as long as it contains all authors names right ? So at the end, the changes on distutils setup() side would be: - authors (goes in Author field - with "," separations ) - contact_email (goes in Author-email field) - deprecation of the "author", "author_email", "maintainer" and "mainainer_email" arguments So the metadata doesn't change and we have what we want. |
|||
msg93360 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2009-09-30 12:30 | |
Tarek Ziadé wrote: > So at the end, the changes on distutils setup() side would be: > > - authors (goes in Author field - with "," separations ) > - contact_email (goes in Author-email field) > - deprecation of the "author", "author_email", > "maintainer" and "mainainer_email" arguments > > So the metadata doesn't change and we have what we want. -1 on that idea :-) The meta-data is only used by PyPI and perhaps a handful of other tools. The setup() keyword parameters OTOH are used by most packages out there, so any change to these has to be carefully planned. Overall, I find the presented use case not really relevant enough to warrant such a huge change. Even less so, since there is a solution that works today without any changes. The addition of the maintainer meta-data field would not hurt anyone and create more consistency. The rest is just documenting best practices. |
|||
msg93363 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-30 12:54 | |
> The meta-data is only used by PyPI and perhaps a handful > of other tools. [...] > The addition of the maintainer meta-data field would > not hurt anyone and create more consistency. since PyPI has its own Role system (owner, maintainer) managed by the user who registered the distribution, independantly from the Metadata, what use case are you thinking about for a new Maintainer field ? When an author is not maintaining a package anymore, and an extra name has to be added, we previously said that this extra name could be added in the author field. So what would be the gain to distinguish maintainers form authors, and how PyPI will deal with the fact that a package will have maintainers in its metadata, and maintainers at PyPI that may differ ? |
|||
msg93364 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2009-09-30 13:02 | |
Tarek Ziadé wrote: > > Tarek Ziadé <ziade.tarek@gmail.com> added the comment: > >> The meta-data is only used by PyPI and perhaps a handful >> of other tools. > [...] >> The addition of the maintainer meta-data field would >> not hurt anyone and create more consistency. > > since PyPI has its own Role system (owner, maintainer) managed by the > user who registered the distribution, independantly from the Metadata, > what use case are you thinking about for a new Maintainer field ? PyPI is just an application using the meta-data - and the only one I know of. I'm just suggesting to add the meta-data field in order to recreate consistency - not advocating that setup() parameter or its use. > When an author is not maintaining a package anymore, and an extra name > has to be added, we previously said that this extra name could be added > in the author field. > > So what would be the gain to distinguish maintainers form authors, and > how PyPI will deal with the fact that a package will have maintainers in > its metadata, and maintainers at PyPI that may differ ? That's up for the package owners to sort out. I would expect the maintainer to do a new release and update the maintainer field. |
|||
msg93365 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-09-30 13:15 | |
> I'm just suggesting to add the meta-data field in order to recreate > consistency - not advocating that setup() parameter or its use. Yes but fixing this inconsitency can be done on either side: A - remove the maintainer and maintainer_email B - add the Maintainer and Maintainer-email in the metadata While I understand your PoV about the fact that B/ is not impacting existing packages and doesn't require any deprecation, I would like to find some use cases for having such fields in the Metadata, other than fixing the inconsistency. If we don't have a use case, I'd go for A/ |
|||
msg93409 - (view) | Author: Dariusz Suchojad (dsuch) | Date: 2009-10-01 15:22 | |
Hello, funny the bug report should surface in the very same time I was looking for a way to put 2 authors in the 'author' field :-) [Antoine Pitrou (pitrou)] > It is still unknown what use case the new "author" scheme would solve > that the old one doesn't I believe I have such a use case. I'm in the middle of taking over a Python package and I would like to give credits to the original author who passed the development over to me. You see, *he is* the author of 95% of the code, it seems unfair to replace his name with my own. I thought I could simply use a list of authors but the 'author' field hasn't been designed for it. [Antoine Pitrou (pitrou)] > (does someone want the "author"field to be machine parsable? > for what purpose?), I'm just a regular user and when I see a field described as a 'meta' one then I'm actually not wondering how any future tools will take advantage of it. It being a 'meta' I understand it's mostly meant to be interpreted by machines which, funnily enough, seems to be just to the contrary of what you say. Of course one can put anything they wish into 'author', it could even be CSV or XML but that's not the point, the point is that some things simply have two and more authors and inserting the mailing list isn't exactly the same. Sure, I can simply put it all in an AUTHORS file but again it's not the same, what would be the 'author' field for then? If someone were to ask me then I'd say there should only be the 'author' and 'contributor' fields which both have a clear meaning in open-source world, accepting both a string and a list/tuple in format of 'Foo Bar <foobar@example.com>' which makes for easy parsing and other fields discussed here should be deprecated. No one likes type checking but at least it would provide backwards-compat for the most widely used field. Just my 2c. author = 'Foo Bar <foobar@example.com>' author = ['Foo Bar <foobar@example.com>', 'Baz Frobble <bazfrobble@example.com>'] But hey, I still very much like distutils :-) and I understand all the backwards-compatibility concerns, but as a user I can clearly see a need for /some/ way to specify more than one author without having to wonder what will any not-yet-written tool do with this or any other meta field. |
|||
msg93508 - (view) | Author: anatoly techtonik (techtonik) | Date: 2009-10-03 21:20 | |
I wonder what does Guido think about this bikeshed? |
|||
msg93555 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2009-10-04 19:19 | |
Tarek Ziadé wrote: > > Tarek Ziadé <ziade.tarek@gmail.com> added the comment: > >> I'm just suggesting to add the meta-data field in order to recreate >> consistency - not advocating that setup() parameter or its use. > > Yes but fixing this inconsitency can be done on either side: > A - remove the maintainer and maintainer_email > B - add the Maintainer and Maintainer-email in the metadata > > While I understand your PoV about the fact that B/ is not impacting > existing packages and doesn't require any deprecation, I would like to > find some use cases for having such fields in the Metadata, other than > fixing the inconsistency. > > If we don't have a use case, I'd go for A/ Having a maintainer for a package is not at all uncommon. Whether you put that maintainer into a separate field or not is really a mix of respect/taste/culture. I'd go for B, since we already have the maintainer setup() variable and just need to add the missing meta-data field. Whether this gets used or not is up to 3rd party code using the meta-data to decide and not really a distutils question. |
|||
msg93647 - (view) | Author: anatoly techtonik (techtonik) | Date: 2009-10-06 12:53 | |
>> Tarek Ziadé <ziade.tarek@gmail.com> added the comment: >> Yes but fixing this inconsitency can be done on either side: >> A - remove the maintainer and maintainer_email >> B - add the Maintainer and Maintainer-email in the metadata >> If we don't have a use case, I'd go for A/ > > Having a maintainer for a package is not at all uncommon. > > Whether you put that maintainer into a separate field or not > is really a mix of respect/taste/culture. Please, be specific. PyPi maintainer or trac-plugin package maintainer or debian package maintainer? Which should be mentioned in debian package for a trac plugin uploaded to PyPi for easy_install? > I'd go for B, since we already have the maintainer setup() > variable and just need to add the missing meta-data field. > > Whether this gets used or not is up to 3rd party code > using the meta-data to decide and not really a distutils > question. Is distutils format extensible? Can you create example of extending distutils format using this maintainer use case, so that every project can add their own maintainer fields if they need them? If it is impossible then I suggest to stop this discussion and start planning extensible distutils2 format with setup2.py and other2 files. |
|||
msg93648 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2009-10-06 13:04 | |
anatoly techtonik wrote: > > anatoly techtonik <techtonik@gmail.com> added the comment: > >>> Tarek Ziadé <ziade.tarek@gmail.com> added the comment: > >>> Yes but fixing this inconsitency can be done on either side: >>> A - remove the maintainer and maintainer_email >>> B - add the Maintainer and Maintainer-email in the metadata > >>> If we don't have a use case, I'd go for A/ >> >> Having a maintainer for a package is not at all uncommon. >> >> Whether you put that maintainer into a separate field or not >> is really a mix of respect/taste/culture. > > Please, be specific. PyPi maintainer or trac-plugin package maintainer > or debian package maintainer? Which should be mentioned in debian > package for a trac plugin uploaded to PyPi for easy_install? The maintainer of the plugin. >> I'd go for B, since we already have the maintainer setup() >> variable and just need to add the missing meta-data field. >> >> Whether this gets used or not is up to 3rd party code >> using the meta-data to decide and not really a distutils >> question. > > Is distutils format extensible? Can you create example of extending > distutils format using this maintainer use case, so that every project > can add their own maintainer fields if they need them? If it is > impossible then I suggest to stop this discussion and start planning > extensible distutils2 format with setup2.py and other2 files. The meta-data format is versioned, so it's well possible to add new fields to it or make changes in core distutils. It's even possible to extend if in custom setup scripts, provided you know your way around in distutils. Have a look at dist.py. You'll need to write a Distribution sub-class and register this via the distclass setup() parameter. |
|||
msg93651 - (view) | Author: anatoly techtonik (techtonik) | Date: 2009-10-06 15:07 | |
On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg <report@bugs.python.org> wrote: >> >> Please, be specific. PyPi maintainer or trac-plugin package maintainer >> or debian package maintainer? Which should be mentioned in debian >> package for a trac plugin uploaded to PyPi for easy_install? > > The maintainer of the plugin. > So, the maintainer of the plugin is mentioned in setup.py, but this field is also used in PyPi and the person who maintains it there wants some attribution. Should this person change maintainer field to himself? >> Is distutils format extensible? Can you create example of extending >> distutils format using this maintainer use case, so that every project >> can add their own maintainer fields if they need them? If it is >> impossible then I suggest to stop this discussion and start planning >> extensible distutils2 format with setup2.py and other2 files. > > The meta-data format is versioned, so it's well possible to > add new fields to it or make changes in core distutils. No, that's not the way. Suppose we have three independent external frameworks that use setup.py files for deploying their plugins/components. All three need to extend distutils format. Which version should they choose? What if official distutils release will decide to use this version? Will other tools parse all these new versions correctly? > It's even possible to extend if in custom setup scripts, > provided you know your way around in distutils. Have a > look at dist.py. You'll need to write a Distribution sub-class > and register this via the distclass setup() parameter. As you may see I definitely do not know my way in distutils. =) Can you show the example of extending setup.py with pypi_maintainers field, that includes emails that should be granted maintainer rights by PyPi automatically on setup.py submission? It is not that I am challenging you to something - I just want to say that there are not many people who knows distutils like you to create the best solution for this user story. Even if it can be a tedious task the outcome is really important for further distutils usability improvement. |
|||
msg93654 - (view) | Author: Marc-Andre Lemburg (lemburg) * | Date: 2009-10-06 15:24 | |
anatoly techtonik wrote: > > anatoly techtonik <techtonik@gmail.com> added the comment: > > On Tue, Oct 6, 2009 at 4:04 PM, Marc-Andre Lemburg > <report@bugs.python.org> wrote: >>> >>> Please, be specific. PyPi maintainer or trac-plugin package maintainer >>> or debian package maintainer? Which should be mentioned in debian >>> package for a trac plugin uploaded to PyPi for easy_install? >> >> The maintainer of the plugin. >> > > So, the maintainer of the plugin is mentioned in setup.py, but this > field is also used in PyPi and the person who maintains it there wants > some attribution. Should this person change maintainer field to > himself? We have a long description field for such things. If you look on PyPI that field is even being used for complete documentation of a package, so adding a note about some extra maintainer is certainly within range. >>> Is distutils format extensible? Can you create example of extending >>> distutils format using this maintainer use case, so that every project >>> can add their own maintainer fields if they need them? If it is >>> impossible then I suggest to stop this discussion and start planning >>> extensible distutils2 format with setup2.py and other2 files. >> >> The meta-data format is versioned, so it's well possible to >> add new fields to it or make changes in core distutils. > > No, that's not the way. Suppose we have three independent external > frameworks that use setup.py files for deploying their > plugins/components. All three need to extend distutils format. Which > version should they choose? What if official distutils release will > decide to use this version? Will other tools parse all these new > versions correctly? There's only one official distutils meta-format: that of core distutils. Up until now, we've only added new fields, so old tools will continue to work (but not know about the new fields). >> It's even possible to extend if in custom setup scripts, >> provided you know your way around in distutils. Have a >> look at dist.py. You'll need to write a Distribution sub-class >> and register this via the distclass setup() parameter. > > As you may see I definitely do not know my way in distutils. =) Can > you show the example of extending setup.py with pypi_maintainers > field, that includes emails that should be granted maintainer rights > by PyPi automatically on setup.py submission? It is not that I am > challenging you to something - I just want to say that there are not > many people who knows distutils like you to create the best solution > for this user story. Even if it can be a tedious task the outcome is > really important for further distutils usability improvement. I don't have time for such challenges. Like I said: it's possible and easy to do, but that doesn't necessarily mean that adding custom fields to the meta-file format should be encouraged. I also don't think that distutils meta data should be used for automatic administration of tools such as PyPI. It has purely informational character and helps in searching or browsing Python packages. Nothing more. |
|||
msg94520 - (view) | Author: Tarek Ziadé (tarek) * | Date: 2009-10-26 22:08 | |
This discussion is taken to distutils-SIG, and a PEP 345 update is being worked out there. (look for 'RFC PEP 345' in Distutils archives) I am closing this issue and proposes that we continue there. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:56:53 | admin | set | github: 51241 |
2009-10-26 22:08:52 | tarek | set | status: open -> closed messages: + msg94520 |
2009-10-06 15:24:06 | lemburg | set | messages: + msg93654 |
2009-10-06 15:07:39 | techtonik | set | messages: + msg93651 |
2009-10-06 13:04:25 | lemburg | set | messages: + msg93648 |
2009-10-06 12:53:10 | techtonik | set | messages: + msg93647 |
2009-10-04 19:19:55 | lemburg | set | messages: + msg93555 |
2009-10-03 21:20:24 | techtonik | set | messages: + msg93508 |
2009-10-01 15:22:50 | dsuch | set | nosy:
+ dsuch messages: + msg93409 |
2009-09-30 13:15:49 | tarek | set | messages:
+ msg93365 title: Adding a Contributor field in PEP 314 -> PEP 314 inconsistency (authors/author/maintainer) |
2009-09-30 13:02:02 | lemburg | set | messages: + msg93364 |
2009-09-30 12:54:14 | tarek | set | messages: + msg93363 |
2009-09-30 12:30:35 | lemburg | set | messages: + msg93360 |
2009-09-30 12:11:15 | tarek | set | messages: + msg93358 |
2009-09-30 11:50:09 | lemburg | set | messages: + msg93357 |
2009-09-30 11:26:23 | techtonik | set | messages: + msg93356 |
2009-09-29 14:56:43 | lemburg | set | messages: + msg93297 |
2009-09-29 14:45:29 | tarek | set | messages: + msg93296 |
2009-09-29 14:28:40 | tarek | set | messages: + msg93294 |
2009-09-29 14:24:57 | lemburg | set | messages: + msg93293 |
2009-09-29 14:09:20 | tarek | set | messages: + msg93292 |
2009-09-29 13:54:34 | pitrou | set | messages: + msg93291 |
2009-09-29 13:50:52 | lemburg | set | messages: + msg93290 |
2009-09-29 13:44:59 | tarek | set | messages: + msg93289 |
2009-09-29 13:31:58 | pitrou | set | messages: + msg93288 |
2009-09-29 13:28:10 | tarek | set | nosy:
+ lemburg messages: + msg93287 |
2009-09-29 13:18:12 | pitrou | set | messages: + msg93286 |
2009-09-29 13:09:02 | tarek | set | messages: + msg93285 |
2009-09-29 12:16:01 | pitrou | set | nosy:
+ pitrou messages: + msg93284 |
2009-09-28 21:00:41 | techtonik | set | messages: + msg93234 |
2009-09-28 17:02:00 | tarek | set | messages: + msg93219 |
2009-09-28 16:49:42 | techtonik | set | messages: + msg93217 |
2009-09-28 10:56:02 | tarek | set | versions:
+ Python 2.7, Python 3.2 resolution: rejected -> title: multiple authors in setup.by -> Adding a Contributor field in PEP 314 messages: + msg93204 type: enhancement |
2009-09-28 10:32:01 | techtonik | set | status: closed -> open messages: + msg93203 |
2009-09-28 09:17:29 | tarek | set | status: open -> closed resolution: rejected |
2009-09-28 07:54:06 | tarek | set | messages: + msg93194 |
2009-09-25 15:03:11 | techtonik | create |