Re: [Launchpad-dev] New feature in Launchpad TestCase base class
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2010 09:47 PM, Tim Penhey wrote: This uses a Fixture that jml wrote a while ago for the scanner (which has since been removed). The fixture code was moved to lp.testing.fixture. If you have a need to use something in your tests that has a setUp and tearDown, you can define a fixture, and use the TestCase method installFixture. This sounds a lot like a Context Manager. Should they be unified? If not, how should we choose which to use? Aaron -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvgIh0ACgkQ0F+nu1YWqI3seQCZAUj5OmttkMJye4rzC9ySnS27 dE8Anj0UrLT3GqM2KErZ4FLuepXRwPe6 =hjrl -END 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] New feature in Launchpad TestCase base class
On Tue, May 4, 2010 at 2:33 PM, Aaron Bentley aa...@canonical.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/2010 09:47 PM, Tim Penhey wrote: This uses a Fixture that jml wrote a while ago for the scanner (which has since been removed). The fixture code was moved to lp.testing.fixture. If you have a need to use something in your tests that has a setUp and tearDown, you can define a fixture, and use the TestCase method installFixture. This sounds a lot like a Context Manager. Should they be unified? If not, how should we choose which to use? They serve a similar purpose, to be sure. Please forgive me, but the best way I can answer right now is to think out loud and not come to a conclusion. I hope it helps. A bunch of things have setUp and tearDown methods, things like bzr Server objects. Some of these things are relatively complicated and benefit from having an addCleanup method. Hence, the Fixture base class. I'm going to call anything with a setUp and tearDown method a fixture for the rest of this email. Since these fixtures are frequently used in tests, it's nice to have a convenient way of saying run this test with this fixture. Especially since fixture.setUp(); self.addCleanup(fixture.tearDown) is boilerplate. self.installFixture(FooFixture()) seems as good a way as any, especially in Python 2.4 land. In Python 2.5 land, we have Context Managers. I guess any test that uses addCleanup now (never mind Fixture) could be rewritten to use a context manager instead. I'm genuinely uncertain as to whether that would be an improvement, but guess not. It would certainly be nice to have something like installFixture that takes a Context Manager instead of a thing that has setUp and tearDown. It would probably be nice to have a thing that adapts objects with setUp/tearDown and turns them into Context Managers, since it would eliminate the need for two methods that do basically the same thing, and since it would let us use things like bzr Servers with the 'with' notation. Maybe Launchpad classes that have setUp and tearDown (like Fixture) should be changed to be context managers. I genuinely don't know whether that would be an improvement. I don't really know how many we have (excluding tests). I also don't know how many context managers we have. 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] Want feedback on LaunchpadSharp
Manish, Launchpad provides a WADL file describing the API for the web-service. I wrote a WADL-C# converter called wadlsharp[1] . Actually with minor modifications it can even create VB code but that is not the current target. wadlsharp is just a library and I am yet to write it's documentation. I created wadlsharp just to create the C# client code so that customizing the generated C# code can as easy as possible. I have released v0.1 of wadlsharp. Get the code from bzr[2] or download the tarball[3] First, I'm grateful that you're taking the time to write a .NET client for the web service. However, I think your current design will cause trouble later on for you and your users. Let me explain. I don't know any C#, so I don't understand what happens inside wadlsharp, but I believe your problems start there, with the generation of C# client code for later customization. I'm looking at LpClientProxy.cs in lpsharp, and it looks like it's the output of wadlsharp, or some wadlsharp-aided transformation of the WADL served by Launchpad on a specific date. I believe this design is a mistake, for three reasons. All three reasons are variants on a single reason: changes to the web service are not automatically reflected in the client. To see the changes, you must upgrade lpsharp. 1. Let's imagine that the Launchpad web service changes in a backwards-incompatible way. Scripts based on launchpadlib will break if they use the feature that changed, but launchpadlib itself will still function, and rewriting the launchpad-based script will fix the problem. Scripts that do not use the feature will still work correctly. From what I can see about the way lpsharp works, lpsharp scripts that do not use the modified feature will still work. But, lpsharp scripts that do use the feature will break, and these scripts _cannot be fixed_ without upgrading lpsharp and _then_ rewriting the script. Because the lpsharp code was generated from an old version of the WADL, lpsharp has no way to find out what the new service looks like. In real life, we take great pains not to make backwards-incompatible changes to the web service. So this scenario is unlikely to happen. But I can't rule it out, especially since it can happen by accident. If it does happen by accident, your users (unlike launchpadlib users) won't be able to use a temporary hack to get their scripts working: that would require a new lpsharp release, and you don't want to do a new release just to deal with a temporary problem on the server side. 2. OK, now imagine that we add a backwards-compatible improvement to the web service. You don't really have to imagine this because we do it all the time. Looking at the service_root_json class in LpClientProxy.cs, I see members like: ... private string _pillars_link; private string _translation_import_queue_entries_collection_link; private string _bug_trackers_collection_link; private string _countries_collection_link; ... For (almost) any one of these links, there was a time in the past year when the web service did not publish that link. The same is true for (almost) all the named operations defined in LPClientProxy.cs as people_findPerson, etc. When we add anything new to the web service, existing installations of launchpadlib will pick up on it. Existing installations of lpslash will not. This is not a catastrophe--obviously scripts written before a feature was published will not break just because they use a lpslash that doesn't know about that feature. But it will be annoying to your users, and it will tie lpslash's upgrade schedule to Launchpad's. Your users will also be effectively unable to use the bleeding-edge 'devel' version of the web service, which changes on a regular basis and which may break its own backwards compatibility from day to day. Which brings me to... 3. Currently there are three versions of the Launchpad web service: beta, 1.0 and devel. Each publishes a slightly (or drastically) different WADL document. This is how we're able to make the strong promises we make about backwards compatibility (see #1). launchpadlib's Launchpad constructor takes a version name, and reads (from the server or from a cache) the appropriate WADL document at startup. If there are 5 versions of the web service, there can be up to 5 cached WADL documents on the user's hard drive, but there's only one copy of launchpadlib. Five pieces of data, one piece of code. By contrast, LpClientProxy.cs is derived from a specific version of the WADL as it was served on a specific date. If there are 5 versions of the web service, there need to be 5 versions of LpClientProxy.cs in a lpslash release. That's five similar pieces of code packaged with lpslash, which need to be updated whenever the web service is updated (once a month, in the limiting case). This isn't a showstopper (unless you consider the inability to access the new features of 'devel' a showstopper), but it violates Don't Repeat Yourself and it'll be
Re: [Launchpad-dev] [Branch ~launchpad-pqm/launchpad/db-devel] Rev 9322: [release-critical=bjornt][r=gary][bug=572077] Revert sendmail.py part
On Mon, May 03, 2010 at 09:46:44AM +1200, Tim Penhey wrote: On Sat, 01 May 2010 08:16:24 you wrote: Merge authors: Björn Tillenius (bjornt) revno: 9322 [merge] committer: Launchpad Patch Queue Manager launch...@pqm.canonical.com branch nick: launchpad timestamp: Fri 2010-04-30 21:13:26 +0100 message: [release-critical=bjornt][r=gary][bug=572077] Revert sendmail.py part of db-devel r9205, so that scripts don't use the zope mailers. Scripts need to be configured, and possibly rewritten, before we can use the zope mailers there. modified: lib/lp/services/mail/sendmail.py Hi Bjorn, As you probably know already, it was me who did this change. Yes. I forgot to send an e-mail about it, since it was Friday evening, and I had better things to do :) You might want to read a blog post of mine, although I hope you don't take it personal ;) (this was just an excellent real-world example) http://tillenius.me/blog/2010/05/03/problems-with-drive-by-fixes/ The primary reason for this was local testing. I wasn't aware of the full consequences of the change, and was trying to QA locally. How should we QA changes locally when dealing with script email? Unfortunately, it's quite difficult. You could log the mail, or the important parts of the mail. Another thing would be to do something special for the development config. I think that mailman has a test smtp server. It might be possible to look into using that one to store the sent mails somewhere. -- Björn Tillenius | https://launchpad.net/~bjornt ___ 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] Want feedback on LaunchpadSharp
Apart from all in the previous mail, I would like to ask a few more questions. All these examples are hypotheical just for sake of discussion and clarification 1) If version 1.0 of LP has a entity *bug* and a method names *checkBugIsValid* , then if you change the name of method to *checkBugValidity* in v2.0 , then the client will generate the proxy for it. Now the problem comes with applications which have always been using method *checkBugIsValid* will break. Isn't it? How does launchpadlib actually deal with it? This means that applications have to be made for a specific version of launchpad API version? If my application is named foo, then it means I need to have backend names libfoo-lp1.0 and libfoo-lp2.0 If only one application has to be maintained, then how will the application know that to check that the bug is valid, it needs to call which method name. Atleast this much hardcoding has to be there. The application needs to know which actual method to call when someone clicks on the button Check if the Bug is Valid 2) I was thinking of making the correct version in the following way: One component which takes in the WADL string and creates the library (dll) which can be loaded at runtime. Applications when started first check which version of LP is available. As per the latest stable release, it downloads the WADL file, sends this to the component mentioned above which created the library and this library is sent back the application which loads it at runtime. Loading modules/assemblies at runtime is supported by CLI. Mono also supports it [ http://www.go-mono.com/docs/index.aspx?link=M%3aSystem.Reflection.Assembly.LoadFile%28System.String%29 ] Once the assembly is loaded (like loading modules in Python), then rest everything continues as required. Is what I said above correct and feasible? Please let me know. By that time I am off to learn Reflection. -- Mainish Sinha http://launchpad.net/~manishsinha ___ 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] PPA key generation is currently broken
I think this might be related to the pygpgme change that was done recently, but can anyone take a guess at why the script is bailing out with this? 2010-05-04 22:00:41 INFOGenerating signing key for PPA for Kristian Klette 2010-05-04 22:02:32 DEBUG Removing lock file: /var/lock/launchpad-ppa- generate-keys.lock Traceback (most recent call last): File /srv/launchpad.net/codelines/current/cronscripts/ppa-generate- keys.py, line 21, in module script.lock_and_run() File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/services/scripts/base.py, line 280, in lock_and_run implicit_begin=implicit_begin, isolation=isolation) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/services/scripts/base.py, line 238, in run self.main() File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/soyuz/scripts/ppakeygenerator.py, line 62, in main self.generateKey(archive) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/soyuz/scripts/ppakeygenerator.py, line 33, in generateKey archive_signing_key.generateSigningKey() File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/archivepublisher/archivesigningkey.py, line 75, in generateSigningKey secret_key = getUtility(IGPGHandler).generateKey(key_displayname) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/canonical/launchpad/utilities/gpghandler.py, line 307, in generateKey secret_keys = list(self.localKeys(result.fpr, secret=True)) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/canonical/launchpad/utilities/gpghandler.py, line 402, in localKeys for key in ctx.keylist(filter, secret): TypeError: first argument must be a string or sequence of strings ___ 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] PPA key generation is currently broken
On 04/05/10 23:28, Julian Edwards wrote: I think this might be related to the pygpgme change that was done recently, but can anyone take a guess at why the script is bailing out with this? 2010-05-04 22:00:41 INFOGenerating signing key for PPA for Kristian Klette 2010-05-04 22:02:32 DEBUG Removing lock file: /var/lock/launchpad-ppa- generate-keys.lock Traceback (most recent call last): File /srv/launchpad.net/codelines/current/cronscripts/ppa-generate- keys.py, line 21, inmodule script.lock_and_run() File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/services/scripts/base.py, line 280, in lock_and_run implicit_begin=implicit_begin, isolation=isolation) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/services/scripts/base.py, line 238, in run self.main() File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/soyuz/scripts/ppakeygenerator.py, line 62, in main self.generateKey(archive) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/soyuz/scripts/ppakeygenerator.py, line 33, in generateKey archive_signing_key.generateSigningKey() File /srv/launchpad.net/codelines/ppa- rev-9329/lib/lp/archivepublisher/archivesigningkey.py, line 75, in generateSigningKey secret_key = getUtility(IGPGHandler).generateKey(key_displayname) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/canonical/launchpad/utilities/gpghandler.py, line 307, in generateKey secret_keys = list(self.localKeys(result.fpr, secret=True)) File /srv/launchpad.net/codelines/ppa- rev-9329/lib/canonical/launchpad/utilities/gpghandler.py, line 402, in localKeys for key in ctx.keylist(filter, secret): TypeError: first argument must be a string or sequence of strings The new pygpgme's result.fpr is now a unicode object, but apparently the filter argument to keylist is still wanted as a bytestring. Max. ___ 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
