[tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Feb 15, 12:20 am, Michael Pedersen mjpe...@gmail.com wrote: Weekly status roundup: *TG2.1 / SQLAlchemy Bug* So, it seems that, with 2.1 and SQLAlchemy 0.7 beta, we have a bug. For now, the short term fix is to make sure to get users to install 0.6.6. The only question is *how* to make this happen. My initial response was to tell people to use our private PyPI. The immediate response is They don't do it now, and we tell them to do so, why will they start listening? So, I have a different proposed solution: We change our setup.py to include our private PyPI in the list of places to look. As much as possible, we even force it to be the *first* place to look. Now, people can make end runs around this issue, and it won't fix existing applications, but if we put this into our quickstart, it will take care of the issues pretty nicely. As an added bonus, it also prevents future problems. The drawback is that, since we're in the middle of a migration, and URLs are changing, I wouldn't want to push this update until at least the web migration is complete. Both the methods you suggest have been tried before and both have failed. Forcing our pypi index, has the opposite problem, if there is a mayor security release, or something that unbreaks something that broke really bad (look for the Extremes package for an example of how it was broken in our pypi and fixed in regular pypi. Putting it into the quickstart has the problem that everyone with the current version of TG will get a broken build. Also it's conceptually wrong your app does not depend on SA 0.6.6. Turbogears does, more specifically repoze.what.plugins.sql therefore *TG* should have the restriction (at least until r.what is fixed) -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG2 Weekly Status Update - February 14, 2011
Hi all, Le 15/02/2011 05:20, Michael Pedersen a écrit : *TG2.1 / SQLAlchemy Bug* So, it seems that, with 2.1 and SQLAlchemy 0.7 beta, we have a bug. For now, the short term fix is to make sure to get users to install 0.6.6. The only question is *how* to make this happen. What I do in my own projects is to require SQLAlchemy0.6.99. This way I am sure pre-0.7 version don't get installed while bugfix releases on the 0.6.x branch do. And when I get compatible with 0.7.x, then I change the requirement to 0.7.99. cheers Christophe -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] TG2 Weekly Status Update - February 14, 2011
On Tue, Feb 15, 2011 at 5:20 AM, Michael Pedersen mjpe...@gmail.com wrote: Basic proficiency with git has been obtained. It's going to take a while before I'm fully comfortable with it. The bitbucket repositories have been fully moved to sourceforge.net, and deleted from bitbucket.org. I have seen that on sf.net there are only 2.0 and master branches. How do you plan to handle a branching strategy for future development? Personally I would suggest to have a branch for each stable release where we can just commit fixes. Currently we should have something like: 2.0 2.1 2.2 with the current master being the 2.1 The 2.2 work should probably be based on the percious work to move dispatch to crank if we want to procede in that way. I did some work on https://bitbucket.org/_amol_/tg-2.2/overview to merge his work with the old tip of the TG repository. Let me know if there is any interest to move that work on sf.net and I'll migrate it to git. This is a mixed bag. Since we have the repositories on sf.net, we have made progress. The web area is a bit of a mess, though, and I'll explain that below in its own section. It also appears that we have a significant issue occurring in SQLAlchemy 0.7beta and TG2.1. I have a proposed solution that I'll document below. I have a strong feeling that we should enforce a set of stable libraries tested with TG. Currently the main problem most people have is that if they install TG it will work or not depending on the current status of the libraries on the PyPI env and we cannot be sure that each library used by TG will continue to work with TG. For example currently installing TG2.0 requires a lot of hand work as it has some problems if you simply install it with the http://www.turbogears.org/2.0/downloads/current/tg2-bootstrap.py script. I'm fine with both the solution of having a TG private PyPI or enforcing precise version in the setup.py But by default we should rely on installing only from there and let the user install upgrades only manually. -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Mon, Feb 14, 2011 at 11:59 PM, Kevin Horn kevin.h...@gmail.com wrote: On the SA list, Mike Bayer made it sound like he's planning on pulling the 0.7beta off of PyPI for the time being. If that is indeed the case, you might want to factor that into whatever plan ends up being made. In that case, we get slightly more time until the next version of 0.7 beta comes out. I'll be surprised if it's more than two weeks, though. On Tue, Feb 15, 2011 at 8:34 AM, jorge.var...@gmail.com jorge.var...@gmail.com wrote: Both the methods you suggest have been tried before and both have failed. So, the solution you're demanding is that we start requiring specific versions, even when those versions may no longer be available on standard PyPI in future? Since that's not actually a viable option, and since our docs already tell people to use our PyPI, unless you can provide another option, we're probably going to have to go with forcing our PyPI. On Tue, Feb 15, 2011 at 8:39 AM, Christophe de Vienne cdevie...@gmail.comwrote: What I do in my own projects is to require SQLAlchemy0.6.99. This way I am sure pre-0.7 version don't get installed while bugfix releases on the 0.6.x branch do. And when I get compatible with 0.7.x, then I change the requirement to 0.7.99. This is a viable way of specifying the requirements, definitely. I'd actually go with 0.7 and 0.8, though. This way, if version 0.6.99 *does*come out, then you will still get it. On Tue, Feb 15, 2011 at 8:44 AM, Alessandro Molina alessandro.mol...@gmail.com wrote: I have seen that on sf.net there are only 2.0 and master branches. How do you plan to handle a branching strategy for future development? I'm still somewhat in the air about this, honestly. Right now, I'm thinking that stable code only will go into master, with development branches occurring. Been reading Professional Git, andf I'll admit it's shaping a lot of my thinking. That doesn't mean it's always right, so I'm keeping myself open to other ides. Personally I would suggest to have a branch for each stable release where we can just commit fixes. Currently we should have something like: 2.0 2.1 2.2 The one major change I would make is that I would not make a 2.2 branch as yet. Right now, the current order of operations needs to be this: - Complete migration to sourceforge.net - Release 2.0.4 (we have some minor bugfixes ready for it) - Release 2.1.1 (again, minor bugfixes already ready) - Begin work on 2.2. The 2.2 work should probably be based on the percious work to move dispatch to crank if we want to procede in that way. I did some work on https://bitbucket.org/_amol_/tg-2.2/overview to merge his work with the old tip of the TG repository. Let me know if there is any interest to move that work on sf.net and I'll migrate it to git. Interest? Yes. However, here's where my first significantly unpopular decision is likely to happen. I don't think we can incorporate those changes for 2.2. We have way too many issues that need to be resolved. Open bugs in the code and in the documentation, and a major documentation overhaul, are all required fixes. Changing the dispatch mechanism again? I don't think I can get behind that as yet. Our API is too undocumented, too unstable, and it's causing chaos. Every release, we're deprecating how dispatch happens. This is not good for our users, and therefore is ultimately not good for us. Getting the changes migrated in on their own branch could be a good thing. However, they would belong off of a proposed updates branch, and not merged for some time. I have a strong feeling that we should enforce a set of stable libraries tested with TG. Currently the main problem most people have is that if they install TG it will work or not depending on the current status of the libraries on the PyPI env and we cannot be sure that each library used by TG will continue to work with TG. Agreed. That's why I'm looking to force the installers to use our private PyPI as their first repository. It makes us responsible for keeping our copies of the .egg files current, but that's a small price to pay for being able to say easy_install tg.devtools or pip install tg.devtools. -- Michael J. Pedersen My IM IDs: Jabber/peder...@icelus.tzo.com, ICQ/103345809, AIM/pedermj022171 Yahoo/pedermj2002, MSN/pedermj022...@hotmail.com -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 15.02.2011 14:47, schrieb Alessandro Molina: On Tue, Feb 15, 2011 at 2:34 PM, jorge.var...@gmail.com jorge.var...@gmail.com wrote: Both the methods you suggest have been tried before and both have failed. Forcing our pypi index, has the opposite problem, if there is a mayor security release, or something that unbreaks something that broke really bad (look for the Extremes package for an example of how it was broken in our pypi and fixed in regular pypi. We have off course to keep our pypi updated when fixes for the libraries that we use appear. This shouldn't be a problem as we use TG ourselves and so we know when it won't install anymore. I wanted to answer the same, I don't see the problem with the approach itself, but with us failing to properly maintain our own PyPI. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 15.02.2011 16:15, schrieb Michael Pedersen: This is a viable way of specifying the requirements, definitely. I'd actually go with 0.7 and 0.8, though. The problem with that is that setuptools considers 0.7a1, 0.7b1, 0.7rc1 all 0.7 (which makes some sense). So 0.7a1 is probably what you want. -- Christoph -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Le 15/02/2011 16:28, Christoph Zwerschke a écrit : Am 15.02.2011 16:15, schrieb Michael Pedersen: This is a viable way of specifying the requirements, definitely. I'd actually go with 0.7 and 0.8, though. The problem with that is that setuptools considers 0.7a1, 0.7b1, 0.7rc1 all 0.7 (which makes some sense). So 0.7a1 is probably what you want. What about 0.7dev ? Christophe -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
Re: [tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
Am 15.02.2011 16:46, schrieb Christophe de Vienne:
What about 0.7dev ?
Right, 0.7dev is sorted even before 0.7a
with the current setuptools and distutils:
from pkg_resources import parse_version as V
V('0.7.dev1') == V('0.7dev1') V('0.7a1') V('0.7b1') V('0.7')
True
However, 0.7dev is not valid and 0.7.dev 0.7a
with the newly proposed version schema of PEP386:
from verlib import NormalizedVersion as V
V('0.7a1') V('0.7b1') V('0.7.dev1') V('0.7')
True
V('0.7dev')
verlib.IrrationalVersionError: 0.7dev
So maybe we need to combine both: 0.7.dev1, 0.7a1
-- Christoph
--
You received this message because you are subscribed to the Google Groups
TurboGears Trunk group.
To post to this group, send email to turbogears-trunk@googlegroups.com.
To unsubscribe from this group, send email to
turbogears-trunk+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en.
[tg-trunk] Re: TG2 Weekly Status Update - February 14, 2011
On Feb 15, 4:29 pm, Michael Pedersen m.peder...@icelus.org wrote: On Tue, Feb 15, 2011 at 4:08 PM, Kevin Horn kevin.h...@gmail.com wrote: Maybe there should be a TG-based private PyPI app that can be told to check for new versions? And then expose them to the private PyPI when instructed to? Perhaps it could take some kind of switch or something so that devs/testers would get the latest version of all packages, while the general users would get only the approved versions? Dammit. Now I have another new item on my todo list. I haven't even managed to cross all the other items off of it yet! Yes, I like this idea, quite a bit. Set up a scheduled job to pull down new versions, let people download testing/etc versions. This is an excellent idea. Thank you. For the record, I just looked on PyPI and SQLAlchemy 0.6.6 is now again the latest there (Mike seems to have removed 0.7dev). -- You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com. To unsubscribe from this group, send email to turbogears-trunk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.
