possible to setup old project (different dependencies) as a library ?
16 views
Skip to first unread message
Abraham Varricatt
Jan 4, 2016, 7:16:25 AM1/4/16
to Django users
A team I'm working with has its hands full with an old Django 1.4 project (python 2.7). We're thinking of refactoring the code-base and migrating things over to the latest Django 1.9. Thing is, we can't abruptly stop working on the old 1.4 code base. So, an idea was floated - to start a new Django 1.9 project but refer the old code-base as a library using wrappers (and continue development of the old code base in parallel). Is this possible? If so, how can it be done?
The problem, is how to deal with having different environments for both projects. For example, the old django 1.4 based project used the piston library. This no longer works with Django 1.9, and I'd rather not hack around it. Is it possible, to create a virtualenv for the old project to link to (and work with), but use a different virtualenv for the new project, but allow the new project to import/use the old project as a library? Note: we are talking about two different django projects with different settings.py files as well.
Searching online leads me to information on setting up a virtualenv for a single project, but nothing on linking together two projects with different virtualenv environments.
Feeling a bit lost,
Abraham V.
Jani Tiainen
Jan 4, 2016, 7:29:57 AM1/4/16
to django...@googlegroups.com
Hi,
You can use your older project "as a library". But it won't magically enable using outdated libraries. IOW, even if you use 1.4 based project as a library you still need to upgrade parts that are not 1.9 compatible, that also means that all your libraries must be upgraded to support Django 1.9.
Virtualenvironment is used to create sandboxed environment for Python where you can install libraries without affecting system or other virtualenvs. And only one environment can be active at any time.
Depending of size of your codebase you can do two things - do one-time port everything to 1.9 and continue development there.
If codebase is so large that it takes significant time, you can do one-time port to different branch of your codebase, do the upgrades and finally backport all new features that are not yet ported over.
You can use your older project "as a library". But it won't magically enable using outdated libraries. IOW, even if you use 1.4 based project as a library you still need to upgrade parts that are not 1.9 compatible, that also means that all your libraries must be upgraded to support Django 1.9.
Virtualenvironment is used to create sandboxed environment for Python where you can install libraries without affecting system or other virtualenvs. And only one environment can be active at any time.
Depending of size of your codebase you can do two things - do one-time port everything to 1.9 and continue development there.
If codebase is so large that it takes significant time, you can do one-time port to different branch of your codebase, do the upgrades and finally backport all new features that are not yet ported over.
--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/26a27d48-590e-46b1-9d25-193f6c3583d4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Abraham Varricatt
Jan 4, 2016, 7:52:27 AM1/4/16
to Django users
I was afraid that someone might say that. I'm going to stubbornly keep searching for another answer for a little longer. But thanks Jani, for confirming a suspicion.
-Abraham V.
Andreas Kuhne
Jan 4, 2016, 8:23:54 AM1/4/16
to django...@googlegroups.com
As a person who has done this on 2 separate occasions, I also think that the best way would be to start a rewrite and upgrade ASAP.
However, having said that. I think you COULD be able to run the old code in a django 1.9 environment, by checking for different methods. For example in django 1.4 a method on a manager is called get_query_set, however in django 1.9 it's called get_queryset. So what you could do, is check if the method exists and call it, otherwise call the newer method.
However, I would think this would take a lot of coding and create new issues - I just don't think it would be worth it.
However, having said that. I think you COULD be able to run the old code in a django 1.9 environment, by checking for different methods. For example in django 1.4 a method on a manager is called get_query_set, however in django 1.9 it's called get_queryset. So what you could do, is check if the method exists and call it, otherwise call the newer method.
However, I would think this would take a lot of coding and create new issues - I just don't think it would be worth it.
Regards,
Andréas
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c3503be8-aa12-475b-8b7b-242d1810ca11%40googlegroups.com.
André Jarussi
Jan 4, 2016, 8:28:17 AM1/4/16
to Django users
Hello Abraham ...
I recently had to upgrade my django from version 1.4 to 1.8 .. I'm not sure the size of your project, but for me, it wasn't as hard as it looks.
I couldn't stop new features for a while to migrate to 1.8 so I was doing by pieces ... 1.4 to 1.5 .. deploy .. 1.5 to 1.6 .. deploy .. It took longer, but it was possible.
That way I was able to develop new features and upgrade ...
You should try .. Most of the things that break is outside of django, and basically, updating the external lib versions works.
[]'s
Reply all
Reply to author
Forward
0 new messages