Chris wrote > From the way I see it, there are 4 options: > 1. Stay the way we are and convert when 0.8 is actually released
The consequences are currently warnings with recent Python 2.x versions and some failed tests. > 2. Switch to using django-registration tip It is good but requires: - rewrite some related view functions to view classes. - more complicated upgrade for users who customized something. - It is more seamless and easier for users who upgrade to do similar backward incompatible changes together which will be also necessary soon. (generic view functions to view classes) > 3. Fork registration and include it in satchmo natively I am against. Prolongating of support for registration 0.7 is possible only for a short time, because all function-based generic views will be deprecated in favour of class-based with Django 1.5. 4. Fork it and include it as a separate package This is not perfect, but it is easy and backward compatible temporary solution yet. Most users will not notice a change. It requires only a clone to Chris's account, replace installation source string on several places and required version number in satchmo_check.py. (I have bumped version num in my clone to 0.7.1.) The link can be later upgraded to either 0.8, tip or to some checked new fixed changeset. I think, it is better currently to wait with rewriting other views because class-based views are supported not until Django 1.3. Satchmo 0.9.2 should (can still) support both Django 1.2 and Django 1.3. (I did not read neither registration 0.8 branch nor class-based generic views in depth. Maybe I am wrong.) -- Hynek On 27 pro, 21:39, Chris Moffitt <ch...@moffitts.net> wrote: > As I've been looking at things trying to get them wrapped up for a release, > one of the dependencies that is a bit of a challenge to manage is > django-registration. We're stuck in limbo where we should probably convert > to using the latest version but it hasn't been officially released yet. > There are probably a few patches I would like to provide so that it is a > little more compatible with the latest django versions. > > My question for this group is, how are you typically integrating Satchmo > into your other django sites? Is Django registration common enough that if > we tried to maintain our own fork, that you would be put at a disadvantage? > In general, I like having the benefits of using other packages but > sometimes we get too tightly restricted to another release cycle. Also, > registration is fairly mature and not going to drastically change in the > future. > > From the way I see it, there are 4 options: > 1. Stay the way we are and convert when 0.8 is actually released > 2. Switch to using django-registration tip > 3. Fork registration and include it in satchmo natively > 4. Fork it and include it as a separate package > > Hynek has already done #4 here > -https://bitbucket.org/hynekcer/django-registration/overview > > These options aren't necessarily mutually exclusive. We could switch to our > own version then switch back later. > > There may be other options but I'm curious to hear what the group thinks > and how they use registration today and what works and what doesn't. > > -Chris -- You received this message because you are subscribed to the Google Groups "Satchmo users" group. To post to this group, send email to satchmo-users@googlegroups.com. To unsubscribe from this group, send email to satchmo-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/satchmo-users?hl=en.
