Closed Bug 794665 Opened 12 years ago Closed 12 years ago

How to release mozbase software to pypi initially?

Categories

(Testing :: Mozbase, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: k0scist, Unassigned)

Details

Attachments

(1 file)

I thought about having this as an email vs a bug report, but I suppose
its somewhere in between.

We have a list of python packages and maintainers on the wiki:

https://wiki.mozilla.org/Auto-tools/Projects/MozBase#PyPI

So when we have a package for initial pypi release, how do we do this?

I'm going to advocate a few things, though I'd love other points of
view:

1. Let's get rid of the listing of packages from
https://wiki.mozilla.org/Auto-tools/Projects/MozBase#PyPI ; IMHO it is
just information looking to get out of date (and in fact it already
is).  This information is gleanable from the mozbase setup.py files

2. Let's move the list of package owners to the mozbase repo.  We can
point to the file from the wiki.  I'm thinking a simple text file with
one person per line.

3. I would like the following script:
- it would upload a new package to pypi
- ... and tag github with the appropriate version
- ... and add all of the people in the list, which now lives in the
repo, as owners

For 3, I suppose (grudgingly, as it will make a fairly complicated
script even more complicated) I advocate using versionbump.py for this
purpose.  This has a few advantages:
- we already use this to upload to pypi and tag
- and for existing versionbumps we can ensure that all of the owners
are current, if the list changes (Of course, we should not delete
pypi owners if they're not on the list this can and IMHO should be
done manually).

This also has (IMHO) an additional implication:
New packages should start with a package version of 0 (or 0.0,
whatever).  This means "not uploaded to pypi".  Then when you run
versionbump.py, you give it whatever initial version number you want.
So given the lack of opposition I'm going to call this a good plan and begin working on it.  From now on, make sure your packages start with a version of 0 or 0.0 until they're uploaded to pypi
Hmmm, hit a barrier right out of the gate on this one :(  While pypi has some sort of API (see e.g. http://wiki.python.org/moin/PyPiXmlRpc ), ABICT there is no good way of setting package owners e.g. from a list.  This...is bad :( :(

An example request to change owner (body not recorded, but you can probably guess what it is like) looks like:

Host: pypi.python.org^M
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/18.0 Firefox/18.0^M
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8^M
Accept-Language: en-US,en;q=0.5^M
Accept-Encoding: gzip, deflate^M
DNT: 1^M
Referer: http://pypi.python.org/pypi?:action=role_form&package_name=mozfile^M
Cookie: pypi=MYAUTHCOOKIE
Authorization: Basic YOUNOGETTHISHEADER
Connection: keep-alive^M
Content-Type: application/x-www-form-urlencoded^M
Content-Length: 163^M
CSRFToken=NjI4ZTdkNGVmYmQ0ZTRiMGJlZGFjYTJkM2U2MGIyZWQzNTdjYjA1YQ%3D%3D&%3Aaction=role&user_name=ctalbert&package_name=mozfile&role_name=Owner&%3Aoperation=Add+Role^M
HTTP/1.1 200 OK^M
Server: nginx/1.1.19^M
Date: Mon, 08 Oct 2012 21:05:44 GMT^M
Content-Type: text/html; charset=utf-8^M
Transfer-Encoding: chunked^M
Connection: keep-alive^M
Set-Cookie: pypi=MYAUTHCOOKIE;path=http://pypi.python.org/^M
Content-Encoding: gzip^M

Ignoring the PITA of auth, there is also a CSRF header which makes things difficult. 

I do think that the rest of the bug should be done that, that is:

- move the pypi owners to the repo
- use versionbump.py to push initial release to pypi (no code changes necessary, AFAIK)
- new packages should have a version 0.0 until pypi release
- document this in https://wiki.mozilla.org/Auto-tools/Projects/MozBase

Also:
- file a bug about how to update owners; this is a PITA to do by hand :(

I'd love suggestions for how to do the owner thing.  While I haven't looked into this particular CSRF token, assuming it is the usual case of hashing (e.g.) the auth cookie with something we can't know, this could be a big show-stopper [and i repeat, ":("]
Attachment #669295 - Flags: review?(wlachance)
As David Burns pointed out, we could use selenium for this.  This is a pretty big dependency though, so we should be careful about it.  

Ultimately, the updating owners is a bigger than just mozbase issue too.  It would be nice to consolidate on some strategy that could be used across mozilla
Comment on attachment 669295 [details] [diff] [review]
add pypi owners to the repo

Review of attachment 669295 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the late review on this.

From what I can gather from what you've written elsewhere in this bug, it doesn't sound we can actually use this information for anything right now? Given that, it feels a little weird to store this in the MozBase repo, but I suppose it doesn't do any harm.
Attachment #669295 - Flags: review?(wlachance) → review+
(In reply to William Lachance (:wlach) from comment #5)
> Comment on attachment 669295 [details] [diff] [review]
> add pypi owners to the repo
> 
> Review of attachment 669295 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Sorry for the late review on this.
> 
> From what I can gather from what you've written elsewhere in this bug, it
> doesn't sound we can actually use this information for anything right now?
> Given that, it feels a little weird to store this in the MozBase repo, but I
> suppose it doesn't do any harm.

Yeah, fair enough.  Let's hold off while we think about what to do about the pypi owners. I don't think me or anyone else manually maintaining them is at all a good use of time, nor have I found any solution to automate this.  That said, I can't really believe this is an unsolved problem
I'm going to close this as WONTFIX.  Sadly, I can't seem to find any way of getting the list of owners out of pypi :(  If you have any information that could be helpful, please reopen.  We really do need this, it just doesn't seem possible to have
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: