[Launchpad-dev] Failed attempt to contribute to lazr.restfulclient
Hello, I was just trying to move some code from lp:udd to lp:lazr.restfulclient where it would be helpful to more people. After pulling a fresh copy of lazr.restfulclient, I had a look at the HACKING document. It doesn't actually say how to run the tests[1]. Since it looked like a buildout project, I tried the bootstrap; buildout approach, and that got me somewhere, except that buildout doesn't work[2]. Once I figured out how to get past that, and buildout ran successfully, I tried running the tests. They failed[3]. I'd really appreciate it if someone who knows more about it could spend a bit of time on lazr.restfulclient, getting it ready for other people to be able to contribute to it. Then I can show my appreciation with patches. cheers, jml [1] https://bugs.launchpad.net/lazr.restfulclient/+bug/848826 [2] https://bugs.launchpad.net/lazr.restfulclient/+bug/848827 [3] https://bugs.launchpad.net/lazr.restfulclient/+bug/848831 ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Failed attempt to contribute to lazr.restfulclient
On Tue, 13 Sep 2011 11:43:23 +0100, Jonathan Lange j...@canonical.com wrote: Once I figured out how to get past that, and buildout ran successfully, I tried running the tests. They failed[3]. I believe there are some tests that are only supposed to be run within launchpad's test harness. Perhaps I'm misremembering and it's launchpadlib that is in that state, but I remember not being able to get a clean test run on one of them without doing it in that way. Such a dependency certainly makes it harder to contribute, and makes it less likely that lazr.restfulclient will be reused by another project. Thanks, James ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Failed attempt to contribute to lazr.restfulclient
On Tue, Sep 13, 2011 at 12:18 PM, James Westby jw+deb...@jameswestby.net wrote: On Tue, 13 Sep 2011 11:43:23 +0100, Jonathan Lange j...@canonical.com wrote: Once I figured out how to get past that, and buildout ran successfully, I tried running the tests. They failed[3]. I believe there are some tests that are only supposed to be run within launchpad's test harness. Perhaps I'm misremembering and it's launchpadlib that is in that state, but I remember not being able to get a clean test run on one of them without doing it in that way. There's a script called 'bin/standalone_test' that fails differently, but with the same root cause: no lazr.uri. Such a dependency certainly makes it harder to contribute, and makes it less likely that lazr.restfulclient will be reused by another project. +1 jml ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Failed attempt to contribute to lazr.restfulclient
On Tue, Sep 13, 2011 at 6:43 AM, Jonathan Lange j...@canonical.com wrote: Hello, I was just trying to move some code from lp:udd to lp:lazr.restfulclient where it would be helpful to more people. After pulling a fresh copy of lazr.restfulclient, I had a look at the HACKING document. It doesn't actually say how to run the tests[1]. Since it looked like a buildout project, I tried the bootstrap; buildout approach, and that got me somewhere, except that buildout doesn't work[2]. It would appear to be a result of using Launchpad to host the lazr.restfulclient downloads. The LP download page is batched and setuptools/distribute don't spider the target of the PyPI Download URL link (thank goodness). The 0.16.0 release was pushed off the first page of downloads so it is no longer available. In the short run I will set lazr.restfulclient to use a newer lazr.restful. In the long run we should change the way downloads are presented if we want people to use LP to host Python packages. Otherwise we should move the lazr package downloads to PyPI. Once I figured out how to get past that, and buildout ran successfully, I tried running the tests. They failed[3]. Using a clean Python (i.e., non-system, no installed packages) or a virtualenv will solve the above problem. This is generally the way buildout should be used unless the system packages are closely managed as part of the development environment. I'll add comments to this effect to the HACKING document. [1] https://bugs.launchpad.net/lazr.restfulclient/+bug/848826 [2] https://bugs.launchpad.net/lazr.restfulclient/+bug/848827 [3] https://bugs.launchpad.net/lazr.restfulclient/+bug/848831 I've replied to the above bugs with comments similar to those in this message. -- Benji York ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Oneiric vs Rabbit
On Sep 12, 2011, at 8:17 PM, Robert Collins wrote: On Tue, Sep 13, 2011 at 11:31 AM, Gary Poster gary.pos...@canonical.com wrote: I would expect: ./setup.py sdist upload --signed and in lp make a 'release' and upload the files there as well. I believe sinzui has some automation around this, or you can use the stuff in lp-tools too. (there is more claimed on https://dev.launchpad.net/ReleaseChecklist but it seems like overkill to me :) - I think we should simplify things as much as possible). Not releasing a Python package on PyPI seems kinda like not releasing. Maybe I'm the odd one out in that perception. setup.py sdist upload --signed *creates* a PyPI release. Of course our python packages should be on PyPI! Ah ok cool. I was pretty sure PyPI needed a register in there (./setup.py sdist register upload). Sorry for the misunderstanding. I re-looked at https://dev.launchpad.net/ReleaseChecklist . I think this is mostly a good process and a good set of expectations. In particular, I think a NEWS.txt file is good practice. I'd only change it in two ways. - Only produce sdists, not eggs. It sounds like you agree with this. - Make no announcements requirements. I'm happy to make these changes if there is consensus. Similarly, if there is consensus, let's remind everyone to follow the advice in the document. Gary ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Failed attempt to contribute to lazr.restfulclient
On Sep 13, 2011, at 8:41 AM, Benji York wrote: In the long run we should change the way downloads are presented if we want people to use LP to host Python packages. Otherwise we should move the lazr package downloads to PyPI. We should have the primary download be in PyPI for Python packages, IMO. We can duplicate in LP for pride's sake if desired, but meanwhile, the rest of the Python world uses PyPI to host their packages, so let's use PyPI. It sounded like Robert was OK with this plan, if not necessarily this line of reasoning, in another thread. Gary ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Build service thoughts
I packaged bzr for openSUSE recently and it was suggested I send some notes on how their build service compares to Launchpad. One difference that surprised me is packages are built instantly as soon as you commit. This can probably be seen as quite a waste of build daemon time since it will be trying to make packages even if what you are working on isn't complete but it does remove a step from the user (in our case quite a hassle filled step since it requires using different tools to upload to the archive until build from branch appears). Build numbers automatically increment for each build which saves the minor hassle of having to do so yourself in the changelog. One source package is built for many distros and distro versions. This would be nice to have in PPAs, again removing a minor hassle from packagers of having to build and upload source packages multiple times. Packages are stored with packaging only and source in a tar file. This simplifies the problem compared to our UDD process of having full source branches in revision control. Given the hassle full source branches seem to make for UDD (still 500 import failures, quilt on top to bzr double revision control, notable new workflows for packagers, definitive source RCS is upstream and ours don't generally match) doing packaging only branches would seem to me to have been an easy win but too late to change now. They have OSC, a command line tool for checkout and commit (similar to subversion in its revision control functions so much more limited than bzr there). It also allows for easy searching of packages, checkouts include personal archives, and it submits merge requests which could be done as bzr plugins with support from Launchpad. They have external users, notably the Linux Foundation which means MeeGo is closely aligned to SUSE. Maybe if Launchpad had been easier for external users to set up MeeGo would be aligned to Ubuntu? I found the web interface generally fiddly to find my way around and it doesn't seem to offer much help. Launchpad feels more logical to me and easier to find help but maybe that's because I use it every day. Jonathan ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Failed attempt to contribute to lazr.restfulclient
On Wed, Sep 14, 2011 at 2:35 AM, Gary Poster gary.pos...@canonical.com wrote: We should have the primary download be in PyPI for Python packages, IMO. We can duplicate in LP for pride's sake if desired, but meanwhile, the rest of the Python world uses PyPI to host their packages, so let's use PyPI. It sounded like Robert was OK with this plan, if not necessarily this line of reasoning, in another thread. +1. LP doesn't allow metadata links to other download sites, so I think we should *either* clearly state that downloads are on url in the project descriptions on Launchpad, *or* upload to both Launchpad and PyPI. (Perhaps the ProductReleaseFinder could rescue us here and maintain mirrored releases automatically). -Rob ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Oneiric vs Rabbit
On Wed, Sep 14, 2011 at 1:36 AM, Gary Poster gary.pos...@canonical.com wrote:
Ah ok cool. I was pretty sure PyPI needed a register in there (./setup.py
sdist register upload). Sorry for the misunderstanding.
register is needed when the project is created, to claim the
namespace. I *think* that that is on the CreatingNewProjects page but
perhaps passively ('should be on pypi') rather than actively ('run
./setup.py register').
I re-looked at https://dev.launchpad.net/ReleaseChecklist . I think this is
mostly a good process and a good set of expectations. In particular, I think
a NEWS.txt file is good practice. I'd only change it in two ways.
- Only produce sdists, not eggs. It sounds like you agree with this.
- Make no announcements requirements.
I'm happy to make these changes if there is consensus. Similarly, if there
is consensus, let's remind everyone to follow the advice in the document.
Yes, if there is a NEWS.txt it should definitely be kept up to date.
And yes, sdists only and not worrying about mechanical announcements
were two changes I had in mind.
-Rob
___
Mailing list: https://launchpad.net/~launchpad-dev
Post to : launchpad-dev@lists.launchpad.net
Unsubscribe : https://launchpad.net/~launchpad-dev
More help : https://help.launchpad.net/ListHelp
[Launchpad-dev] Preparing for 12.04 LTS
Hi Launchpadders, At UDS-O, we had some conversations about helping Launchpad make the migration from 10.04 LTS to 12.04 LTS, and in particular our decision (hopefully to be sustained at UDS-P) to drop Python 2.6 from the archive. As you know, our data center only runs LTS releases, so the Launchpad servers must be able to upgrade from one LTS to the next. Also, we decided to drop Python 2.6 in Ubuntu either when Debian switches to Python 2.7 as the default[1], or during toolchain updates early in the P-cycle. We want to do this for two reasons: first, because including Python 2.6 in 12.04 would mean that we'd have to support it for long after upstream's maintenance commitments end, and because every Python package must be built for all supported Pythons, thus increasing their size[2]. The Launchpad requirement is this: operationally, we do not want to upgrade both the OS version and the Python version at the same time. This means either we provide a way to build and run Launchpad against Python 2.7 in Lucid, or we provide a way to build and run Launchpad against Python 2.6 in 12.04. The plan we hatched at UDS-O was to back port Python 2.7 and a few dozen packages that Francis identified to a Lucid PPA. Then, the Launchpad servers could add that PPA while they were still on 10.04 and switch to Python 2.7 before they upgraded to 12.04. Francis tells me that Launchpad already runs fairly well on Python 2.7 + Oneiric on developer machines, with just one or two test failures. Great plan, except for one thing: I suck. I've had a very difficult time getting that PPA up and running. The biggest problem is that there's a huge dependency stack that ends up needing to be built as well, and determining that stack is a manual, error-prone, and time-consuming processes. For each dependency, we have to decide whether to rebuild the Lucid version of the package (if there is one) or back port the Oneiric version of the package *and* all its dependencies too. Sometimes the package doesn't exist in Lucid; other times the Lucid version of the package doesn't yet support Python 2.7. After some discussion with Francis and Steve Langasek, I think a more fruitful approach will be to forward port Python 2.6 to a P-series PPA, and then make this available to Launchpad, so that it could continue to run on Python 2.6 even after it upgraded to 12.04. Then at its leisure, Launchpad would make the switch to Python 2.7 and get rid of the PPA. I *think* this will work out much better, because we already know that Launchpad runs on Oneiric, so forward porting will be mostly a matter of re-enabling Python 2.6 in the PPA, and rebuilding packages we know already build and work with both 2.6 and 2.7 (i.e. the Oneiric versions). At least at first P will be pretty close to Oneiric, so in theory, that should be a much smaller jump than from Oneiric all the way back to Lucid. Steve brought up one good question, which is whether, after upgrading the LP server to 12.04, you will also rebuild Launchpad. Another question is whether LP needs Python 2.6 to be the default Python, or just a supported version. I think LP can fairly easily specify which version of Python to build against, so ideally, after the LTS upgrade, you'd just enable the PPA and do a manual rebuild of Launchpad against the non-default Python 2.6. Definitely let me know of that's *not* the case. Any and all feedback will be greatly appreciated. I'll commit to working on this once 12.04 opens up, we've removed Python 2.6 from the archive, and rebuilt enough of the P-series archive to have a valid PPA overriding it. Of course, if we backtrack on removing 2.6 from 12.04, then the whole issue is moot. wink Cheers, -Barry [1] The Debian switch had to happen before Oneiric feature freeze for us to even consider it. It didn't happen, so we'll wait until P opens up, but it does look like Debian isn't too far from switching to Python 2.7 as its default. [2] Note that once we remove Python 2.6 from the archive, it will *not* be available in Universe. If it were in the archive at all, we'd still have to build all our Python packages for both versions, since we don't have separate Python packages per major version (we have a separate Python 3 stack, but I won't even go there... yet :). signature.asc Description: PGP signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
Re: [Launchpad-dev] Preparing for 12.04 LTS
Thank you Barry for this extensive write-up of the situation. Answers to your question follows below. On 11-09-13 05:00 PM, Barry Warsaw wrote: Hi Launchpadders, [...] The plan we hatched at UDS-O was to back port Python 2.7 and a few dozen packages that Francis identified to a Lucid PPA. Then, the Launchpad servers could add that PPA while they were still on 10.04 and switch to Python 2.7 before they upgraded to 12.04. Francis tells me that Launchpad already runs fairly well on Python 2.7 + Oneiric on developer machines, with just one or two test failures. That's actually from hear-say and from a while back. I don't know the exact status of this today, but to me the biggest hurdles around this have always been the deployment issues. [...] After some discussion with Francis and Steve Langasek, I think a more fruitful approach will be to forward port Python 2.6 to a P-series PPA, and then make this available to Launchpad, so that it could continue to run on Python 2.6 even after it upgraded to 12.04. Then at its leisure, Launchpad would make the switch to Python 2.7 and get rid of the PPA. The only downside for us with this plan is that we won't be able to update to python 2.7 until our data centre machines are migrated to 12.04 LTS. We are usually eager to update, so probably among the first to upgrade, but that still means that python 2.7 would be something like 8-9 months away. I don't think it's such big a deal, but let's see if others disagree. [...] Steve brought up one good question, which is whether, after upgrading the LP server to 12.04, you will also rebuild Launchpad. We don't rebuild by default after a reboot, but rebuilding isn't a big deal :-) Another question is whether LP needs Python 2.6 to be the default Python, or just a supported version. Just a supported version. We specify which interpreter to use. I think LP can fairly easily specify which version of Python to build against, so ideally, after the LTS upgrade, you'd just enable the PPA and do a manual rebuild of Launchpad against the non-default Python 2.6. Definitely let me know of that's *not* the case. No, that's about it. Any and all feedback will be greatly appreciated. I'll commit to working on this once 12.04 opens up, we've removed Python 2.6 from the archive, and rebuilt enough of the P-series archive to have a valid PPA overriding it. Of course, if we backtrack on removing 2.6 from 12.04, then the whole issue is moot. wink Thanks a lot for following-up on this. -- Francis J. Lacoste francis.laco...@canonical.com signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
