> I've been doing a little bit of thinking lately about how Pinax handles > requirements. I think what we have today is fairly decent. However, in > practice I am finding some issues that I'd like to see us address. These > thoughts have not only come from my work with Pinax as a user, but use cases > I've seen others run into.
Thanks Brian for bringing this up, I couldn't agree more with the need for progress. > Thoughts: > > * pinax-boot.py should not directly install Django let the requirements file > handle it. +1 IIRC, we had something like that for a short period of time in the early days of the bootstrapper. It simply is more natural to handle Django as a library than like a core part of Pinax. > * pinax-admin should no longer require Django to run (to support the above). +1 > * pinax-boot --release (default) will continue to install all dependencies by > default with a new option to not install them. Of course the new option will > require an Internet connection at some point. +1 For the new option, we could additionally either provide a tarball containing all dependencies as source distributions (without Pinax) or a pip bundle to speed up the installation process. > * project-level requirements.txt should be moved to new file (don't have a > name yet) leaving an empty file that simply uses --requirement=unnamedfile > and adds some comments about the usage of the file (this is used for > additional project-level requirements). +1 What about putting the unnamedfile in a subdirectory together with other operational files (e.g. deploy/)? > * pinax-admin clone_project is replaced by a new command called pinax-admin > setup_project. This new command will perform clone_project behavior + install > the requirements.txt file of the project. clone_project behavior can continue > to be emulated with setup_project --no-deps (not thrilled with this, but see > scenarios below). +1 I like the shift in meaning because it will help users to get started more quickly while encouraging the use of project level requirements file. > The goal I am trying to accomplish here is that we enable external projects > as more of a first class citizen, but also make pinax-boot.py an optional > part of installation. Keep in mind that pinax-boot.py does solve a very real > use case and it should still remain a part of Pinax (even as the default > installation method). +1 > The use case being providing a full environment bootstrap. Here are the > possible ways to install Pinax with my proposal implemented: > > SCENARIOS > > pinax-boot.py pinax-env > source pinax-env/bin/activate > pinax-admin setup_project --no-deps basic_project > python manage.py syncdb > > pinax-boot.py --no-deps pinax-env > source pinax-env/bin/activate > pinax-admin setup_project basic_project > python manage.py syncdb > > virtualenv pinax-env > source pinax-env/bin/activate > pip install Pinax > pinax-admin setup_project basic_project > python manage.py syncdb > > virtualenv pinax-env > source pinax-env/bin/activate > pip install Pinax > pinax-admin setup_project --no-deps basic_project > ... tweak requirements to your liking ... > pip install -r requirements.txt > python manage.py syncdb > > As I've previous said I am not particularly sold on using --no-deps in the > default case (first scenario). Suggestions are welcome. When it comes to > --development mode I think the above will still apply (only pinax-boot > scenarios), but we will have specific directions for contributors as we do > now. I could only think of another name for --no-deps, tbh. For example --copy-only. > With my changes in place I think Pinax becomes more natural to use for those > who already deal with installation of pip and virtualenv outside of Pinax > without sacrificing the use case that pinax-boot.py solves for us too. I also > wonder if this might help with buildout users? It certainly will because we'd move away from mixing the tools for installation and isolation. > Jannis and myself have discussed pip bundles as being something Pinax > installation process can use. However, I can't ever see them being used in > the default case, but rather as supplement material. We could distribute them > as a way to install only project requirements without an Internet connection, > but would obviously assume the user has pip already installed. +1 > At this point I am in the thoughts gather phase. If we come to some consensus > I'd like to see about starting on some of this pre-PyCon, but not entirely > sure if that will happen. > > Jannis: since this work falls in your one of your categories of work on Pinax > I wouldn't mind working with you in accomplishing any of this based upon your > thoughts. I'm completely in line with your thoughts on the matter and see them as the natural progresion of the "Pinax project" idea. I'll definitely be available during the Pycon sprints, so let's discuss how we do this. Jannis -- You received this message because you are subscribed to the Google Groups "Pinax Core Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pinax-core-dev?hl=en.
