Merge lp:~jameinel/launchpadlib/win32 into lp:~launchpad-pqm/launchpadlib/devel

Proposed by John A Meinel
Status: Work in progress
Proposed branch: lp:~jameinel/launchpadlib/win32
Merge into: lp:~launchpad-pqm/launchpadlib/devel
Diff against target: None lines
To merge this branch: bzr merge lp:~jameinel/launchpadlib/win32
Reviewer Review Type Date Requested Status
Paul Hummer (community) Approve
Leonard Richardson (community) Approve
Review via email: mp+8471@code.launchpad.net

This proposal supersedes a proposal from 2009-07-09.

To post a comment you must log in.
Revision history for this message
John A Meinel (jameinel) wrote : Posted in a previous version of this proposal

This gets rid of the "bootstrap.py" symlink in favor of a trivial python file that just thunks over to _bootstrap/bootstrap.py

With this patch, I can check out the code on windows, and "py setup.py install" downloads a bunch of stuff and completes successfully.

I don't know if the code is usable yet, but it at least *installs*.

Revision history for this message
John A Meinel (jameinel) wrote :

I found that there is another failure condition, which was pretty easy to fix.

So this patch does:

1) Change the symlink bootstrap.py into a trivial boostrap.py script that just thunks into the real _bootstrap/bootstrap.py
2) Change a trap for:
  if isinstance(cache, str):
to
  if isinstance(cache, basestring):

This is because "tempfile.mkdtemp()" on win32 returns a Unicode string. (Since the underlying filesystem is UTF-16 it makes sense to do so.)

Revision history for this message
Leonard Richardson (leonardr) wrote :

This looks good and works for me. However, if we're going to do this I wonder if it might make sense to just move _bootstrap/bootstrap.py into the top-level directory. That also seems to work, and it's less code. Approved* pending Gary's (probably negative) opinion of that idea.

review: Approve
Revision history for this message
Gary Poster (gary) wrote :

> This looks good and works for me. However, if we're going to do this I wonder
> if it might make sense to just move _bootstrap/bootstrap.py into the top-level
> directory. That also seems to work, and it's less code. Approved* pending
> Gary's (probably negative) opinion of that idea.

My only concern is actually a legal one. I was keeping (trying to keep) the ZPL bits (including the license itself) down in that directory for legal cleanliness.

Another, similar approach would be to remove the top-level bootstrap.py, move _bootstrap dir -> bootstrap, and have the instructions be to run bootstrap/bootstrap.py. As another alternative, we can go for cutesy, like boot/strap.py.

I don't care if we do what you propose though (and that's what I do when the whole package is ZPL), especially if kfogel or someone similarly comfortable with opinions about license stuff like this approves.

Revision history for this message
Karl Fogel (kfogel) wrote :

As long as it's ZPL 2.0 or 2.1, it's fine. We can ship with code copyrighted by others in our tree, as long as the license is AGPLv3-compatible. ZPL 1 is not, but 2.0 and 2.1 are, according to

  http://www.gnu.org/philosophy/license-list.html#Zope20

and also according to the ZPL itself:

  http://www.zope.org/Resources/ZPL

(Note it just claims compatibility with the "GPL", but you can see by reading the license that it's AGPLv3-compatible.)

So, I think you should do whatever is technically best, and not worry about the license. There's other stuff in our tree that is under other free software licenses; compatibility with AGPLv3 is our only concern -- we don't actually have to be the copyright holder in every case.

Revision history for this message
Paul Hummer (rockstar) :
review: Approve
Revision history for this message
Paul Hummer (rockstar) wrote :

What's the status of this branch? The proposal is more than a year old.

Revision history for this message
John A Meinel (jameinel) wrote :

Consider it either merged or rejected. Someone got rid of the symlink in the working dir, so you can checkout launchpadlib on Windows, I don't know whether they used my version or not.

It looks like the change was this one:
  45 Leonard Richardson 2009-07-09
     Moved bootstrap.py up one directory.

And the other fix... there doesn't seem to be a matching mkdtemp call anymore, so it probably doesn't matter either.

Unmerged revisions

44. By John A Meinel

Handle another failure condition on win32.

It seems that 'mkdtemp()' will return a Unicode string on windows,
and launchpadlib was only trapping plain 'str' objects to turn them
into MultipleRepresentationCache objects.

43. By John A Meinel

Get rid of subprocess in favor of updating sys.path and just doing 'import'

42. By John A Meinel

Remove the symlink and replace it with a trivial subprocess invocation.

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
1=== added file 'bootstrap.py'
2--- bootstrap.py 1970-01-01 00:00:00 +0000
3+++ bootstrap.py 2009-07-09 14:02:54 +0000
4@@ -0,0 +1,7 @@
5+#!/usr/bin/env python
6+"""A trivial thunk to call the real bootstrap without needing a symlink."""
7+import os
8+import sys
9+
10+sys.path.insert(0, os.path.join(os.path.dirname(__file__), '_bootstrap'))
11+import bootstrap
12
13=== removed symlink 'bootstrap.py'
14=== target was '_bootstrap/bootstrap.py'
15=== modified file 'src/launchpadlib/_browser.py'
16--- src/launchpadlib/_browser.py 2009-03-20 20:46:06 +0000
17+++ src/launchpadlib/_browser.py 2009-07-09 15:34:19 +0000
18@@ -187,7 +187,7 @@
19 if cache is None:
20 cache = tempfile.mkdtemp()
21 atexit.register(shutil.rmtree, cache)
22- if isinstance(cache, str):
23+ if isinstance(cache, basestring): # On win32 mkdtemp returns Unicode
24 cache = MultipleRepresentationCache(cache)
25 self._connection = OAuthSigningHttp(
26 credentials, cache, timeout, proxy_info)

Subscribers

People subscribed via source and target branches