Here's the email I sent to launchpad-users about this:
---
Right now, if you run this code:
>>> from launchpadlib.launchpad import Launchpad
>>> l = Launchpad.login_with("my app")
>>> print l.bugs[714043].description
It'll run against staging.launchpad.net. To run against the production server you'll need to pass service_root="production" into login_with(). This causes confusion if you don't know what's going on--your changes to the production server are reverted, and the data is slightly out of date.
I wrote a branch (https://code.launchpad.net/~leonardr/launchpadlib/bug-714043/+merge/48842) which preserves staging as the default, but prints a warning whenever the default is used. My branch also makes production the default for *anonymous* access. Anonymous access is read-only, so you can't break anything. You might as well go against production and get the most recent data.
Martin prefers his solution and I prefer mine. Since it comes down to what the majority of developers would prefer, I'd like to get feedback from the community at large. If you have a strong opinion one way or the other, please leave a comment in bug 714043.
Summary of my position: one purpose of the staging server is to let users try things out without ruining their data. Developing a launchpadlib script is exactly the kind of thing you'd want to do on a staging server, since a bug in your script can ruin your data. The warning may be annoying to experienced developers, but it's useful to inexperienced developers, and it gives you a reminder that you'll need to switch to production for your changes to take effect in the real world.
I'll let Martin summarize his own position, but here's my stab at it:
1. Developers in general want to work against production, and printing this warning will just remind them to change it, which they will do immediately.
2. Making production the default everywhere maintains consistency between anonymous and authenticated access.
3. Other web service providers that publish client libraries don't have the client library go against a staging server by default.
Here's the email I sent to launchpad-users about this:
---
Right now, if you run this code:
>>> from launchpadlib. launchpad import Launchpad login_with( "my app") 714043] .description
>>> l = Launchpad.
>>> print l.bugs[
It'll run against staging. launchpad. net. To run against the production server you'll need to pass service_ root="productio n" into login_with(). This causes confusion if you don't know what's going on--your changes to the production server are reverted, and the data is slightly out of date.
In bug 714043 (https:/ /bugs.launchpad .net/launchpadl ib/+bug/ 714043), Martin Pool suggested changing the default to production.
I wrote a branch (https:/ /code.launchpad .net/~leonardr/ launchpadlib/ bug-714043/ +merge/ 48842) which preserves staging as the default, but prints a warning whenever the default is used. My branch also makes production the default for *anonymous* access. Anonymous access is read-only, so you can't break anything. You might as well go against production and get the most recent data.
Martin prefers his solution and I prefer mine. Since it comes down to what the majority of developers would prefer, I'd like to get feedback from the community at large. If you have a strong opinion one way or the other, please leave a comment in bug 714043.
Summary of my position: one purpose of the staging server is to let users try things out without ruining their data. Developing a launchpadlib script is exactly the kind of thing you'd want to do on a staging server, since a bug in your script can ruin your data. The warning may be annoying to experienced developers, but it's useful to inexperienced developers, and it gives you a reminder that you'll need to switch to production for your changes to take effect in the real world.
I'll let Martin summarize his own position, but here's my stab at it:
1. Developers in general want to work against production, and printing this warning will just remind them to change it, which they will do immediately.
2. Making production the default everywhere maintains consistency between anonymous and authenticated access.
3. Other web service providers that publish client libraries don't have the client library go against a staging server by default.
Again, please leave your comments in bug 714043 so we have a unified record of the discussion: https:/ /bugs.launchpad .net/launchpadl ib/+bug/ 714043
Leonard