PEP 314 inconsistency (authors/author/maintainer)

[techtonik]

BPO	6992
Nosy	@malemburg, @pitrou, @tarekziade

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/tarekziade'
closed_at = <Date 2009-10-26.22:08:52.339>
created_at = <Date 2009-09-25.15:03:11.806>
labels = ['type-feature', 'library']
title = 'PEP 314 inconsistency (authors/author/maintainer)'
updated_at = <Date 2009-10-26.22:08:52.338>
user = 'https://bugs.python.org/techtonik'

bugs.python.org fields:

activity = <Date 2009-10-26.22:08:52.338>
actor = 'tarek'
assignee = 'tarek'
closed = True
closed_date = <Date 2009-10-26.22:08:52.339>
closer = 'tarek'
components = ['Distutils']
creation = <Date 2009-09-25.15:03:11.806>
creator = 'techtonik'
dependencies = []
files = []
hgrepos = []
issue_num = 6992
keywords = []
message_count = 35.0
messages = ['93105', '93194', '93203', '93204', '93217', '93219', '93234', '93284', '93285', '93286', '93287', '93288', '93289', '93290', '93291', '93292', '93293', '93294', '93296', '93297', '93356', '93357', '93358', '93360', '93363', '93364', '93365', '93409', '93508', '93555', '93647', '93648', '93651', '93654', '94520']
nosy_count = 5.0
nosy_names = ['lemburg', 'dsuch', 'pitrou', 'techtonik', 'tarek']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue6992'
versions = ['Python 2.7', 'Python 3.2']

[techtonik]

setup.py should allow to specify multiple authors in package description.

[tarekziade]

You can add them in the author field, separated by a space.
It's a free field

[techtonik]

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.

[tarekziade]

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.

[techtonik]

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. =)

[tarekziade]

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.

[techtonik]

Having single authors field is enough, indeed.

[pitrou]

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.

[tarekziade]

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.

[pitrou]

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.

[tarekziade]

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.

[pitrou]

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.

[tarekziade]

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.

[malemburg]

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".

[pitrou]

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 :)

[tarekziade]

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.

[malemburg]

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.

[tarekziade]

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.

[tarekziade]

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

[malemburg]

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.

[techtonik]

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.

[malemburg]

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)

[tarekziade]

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.

[malemburg]

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.

[tarekziade]

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 ?

[malemburg]

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.

[tarekziade]

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/

[dsuch]

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.

[techtonik]

I wonder what does Guido think about this bikeshed?

[malemburg]

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.

[techtonik]

> 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.

[malemburg]

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.

[techtonik]

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.

[malemburg]

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.

[tarekziade]

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.