# Choose which project you would like to use as a starting point.
# Copy that project into a directory outside of the subversion
checkout.
# Make any necessary changes to your manage.py, deployment/*.wsgi etc
in that copied project directory to reflect the location of your Pinax
checkout. The most important variable to change in those files is
PINAX_ROOT.
Wd be nice to have an example of such a setup.
Also, isn't it best to do an export from svn of the project to start
with, instead of copying from a Pinax checkout?
> # Choose which project you would like to use as a starting point. > # Copy that project into a directory outside of the subversion > checkout. > # Make any necessary changes to your manage.py, deployment/*.wsgi etc > in that copied project directory to reflect the location of your Pinax > checkout. The most important variable to change in those files is > PINAX_ROOT.
> Wd be nice to have an example of such a setup.
> Also, isn't it best to do an export from svn of the project to start > with, instead of copying from a Pinax checkout?
On Oct 29, 1:58 pm, greg newman <g...@20seven.org> wrote:
> Unless I'm missing the context of your statement, the basic_project
> and custom_project are examples of this.
Those are under the subversion checkout. The best practices says to
copy the project to a directory outside the subversion checkout. That
will require changes to *.wsgi, manage.py, etc.
> Yes, best to checkout from svn then copy the project.
Not sure we are communicating.
If I copy the project from the subversion checkout, I get all the svn
links copied with it, which I will then need to remove to put it in my
own svn repository. Correct?
> On Oct 29, 1:58 pm, greg newman <g...@20seven.org> wrote: > > Unless I'm missing the context of your statement, the basic_project > > and custom_project are examples of this.
> Those are under the subversion checkout. The best practices says to > copy the project to a directory outside the subversion checkout. That > will require changes to *.wsgi, manage.py, etc.
> > Yes, best to checkout from svn then copy the project.
> Not sure we are communicating.
> If I copy the project from the subversion checkout, I get all the svn > links copied with it, which I will then need to remove to put it in my > own svn repository. Correct?
On Oct 30, 6:49 am, bobhaugen <bob.hau...@gmail.com> wrote:
> The best practices says to put your new project outside the subversion
> checkout.
> Fernando does do the export, but puts his new project *inside* the
> subversion checkout.
> So all he needs to change is ROOT_URLCONF. If you put your new
> project outside, that is not enough.
Ok, just got an export of the basic_project working outside the svn
checkout. In addition to ROOT_URLCONF, all I needed to do to get up
and running using the Django dev server was to change PINAX_ROOT in
manage.py to point to the svn checkout directory.
Not very difficult.
I assume the change to *.wsgi will be similar, but not nearly ready to
deploy yet.
> Fernando does do the export, but puts his new project *inside* the > subversion checkout.
> So all he needs to change is ROOT_URLCONF. If you put your new > project outside, that is not enough.
If you're doing svn export, you could leave it in there. What is to be avoided, IMHO, is the combination of svn checkout and developing your project inside the checkout.
Note that with the change to the .wsgi and manage.py to factor out the PINAX_ROOT, you should just need to change that.
> If you're doing svn export, you could leave it in there. What is to be > avoided, IMHO, is the combination of svn checkout and developing your > project inside the checkout.
Yes, that was my reasoning. An exported directory can live inside a subversion tree without too much trouble. And, also, when I first touched Pinax I wanted to change as little as possible of its configuration and directory structure to stay out of trouble and not lose too much time.
But I thank Bob Haugen for pointing out that I was not following best practices. I updated the article to reflect that. Hopefully I got it right now.
On Oct 30, 1:17 pm, James Tauber <jtau...@jtauber.com> wrote:
> On Oct 30, 2008, at 7:49 AM, bobhaugen wrote:
> > Fernando does do the export, but puts his new project *inside* the
> > subversion checkout.
> > So all he needs to change is ROOT_URLCONF. If you put your new
> > project outside, that is not enough.
> If you're doing svn export, you could leave it in there. What is to be
> avoided, IMHO, is the combination of svn checkout and developing your
> project inside the checkout.
That was going to be my next question: what is the reason for the best
practice, vs what Fernando did?
If I understand what you just wrote correctly, what Fernando did is
perfectly fine. But it wd be bad practice to do a svn checkout and
then start hacking at basic_project or complete_project in place, on
the checked out version.
Correct?
> Note that with the change to the .wsgi and manage.py to factor out the
> PINAX_ROOT, you should just need to change that.
But in both manage.py and *.wsgi.
I also see brosner thinking about refactoring to one place:
http://oebfare.com/logger/pinax/2008/10/30/9/#19:26-896708 19:26 brosner
hmm, i am thinking it might be possible to have PINAX_ROOT in
settings.py.
19:26 jtauber
really?
19:26 jtauber
isn't it a chicken-and-egg problem?
19:27 brosner
might be. hmm, let me think about this a bit more.
> That was going to be my next question: what is the reason for the best > practice, vs what Fernando did?
Let me explain my motives. I use Subversion daily and I'm comfortable with it. I knew that just copying the directory would give me lots of trouble when I decided to updated Pinax. So the "export" idea was natural.
I just exported it alongside the sample project because I was just starting to learn Pinax and didn't want to mess too much with the structure because I didn't know about its dependencies. I had read the customization doc, but it was not so clear to me at first sight.
But the official doc is right. I think we should consider Pinax more like a library, like Django itself, that should be installed and updated on its own, and the website we build should be a separate project, with its own version control. So it should be natural to put Pinax where we store random software (I used ~/opt) and our website where we put things we're working on or software we deploy (I used ~/Projects).
On Thu, Oct 30, 2008 at 4:32 PM, bobhaugen <bob.hau...@gmail.com> wrote:
> On Oct 30, 1:17 pm, James Tauber <jtau...@jtauber.com> wrote: >> On Oct 30, 2008, at 7:49 AM, bobhaugen wrote:
>> > Fernando does do the export, but puts his new project *inside* the >> > subversion checkout.
>> > So all he needs to change is ROOT_URLCONF. If you put your new >> > project outside, that is not enough.
>> If you're doing svn export, you could leave it in there. What is to be >> avoided, IMHO, is the combination of svn checkout and developing your >> project inside the checkout.
> That was going to be my next question: what is the reason for the best > practice, vs what Fernando did?
> If I understand what you just wrote correctly, what Fernando did is > perfectly fine. But it wd be bad practice to do a svn checkout and > then start hacking at basic_project or complete_project in place, on > the checked out version.
> Correct?
I think what Fernando did was exactly right. He explains in a reply and did well :)
> I also see brosner thinking about refactoring to one place: > http://oebfare.com/logger/pinax/2008/10/30/9/#19:26-896708 > 19:26 brosner > hmm, i am thinking it might be possible to have PINAX_ROOT in > settings.py. > 19:26 jtauber > really? > 19:26 jtauber > isn't it a chicken-and-egg problem? > 19:27 brosner > might be. hmm, let me think about this a bit more.
Yeah having PINAX_ROOT in one place seems to be right direction here. I am still not 100% sure how this will be done yet. I have a use case on the TWiD codebase as I build it around Pinax so I will be thinking about this.
> That was going to be my next question: what is the reason for the best > practice, vs what Fernando did?
> If I understand what you just wrote correctly, what Fernando did is > perfectly fine. But it wd be bad practice to do a svn checkout and > then start hacking at basic_project or complete_project in place, on > the checked out version.
> Correct?
Well, I think we're getting outside the realm of what Pinax should suggest and what comes down to just the developers preference regarding svn.
If you export rather than checkout, you won't get new updates. If you checkout and edit in place, your changes may clash with upstream changes (and you'll have to resolve the merge conflicts). If you checkout and copy out the project (being careful to delete the .svn directories in the copy) you won't get updates *for those files* but will for everything else.
It all comes down to how you want to develop and how important the latest pinax changes are to you.
In this scenario, you've just made a custom project called 'varud' which will not be touched by svn update even though it's inside the tree. Nor will changes to that directory propagate up. I believe that is true even if somebody were to commit a varud/ directory into the main repository.
The other option is of course to have it in a tottaly different directory structure. The nice thing though about keeping it within the same root is that in the future, an install script would be very easy to write without having to go outside the root directory. It also makes it easier for people who might be doing their own projects but also updating the core complete_project/ and basic_project/ directories at the same time - that way they don't have to do special configurations with apache and stuff.
On Thu, Oct 30, 2008 at 7:02 PM, James Tauber <jtau...@jtauber.com> wrote:
> On Oct 30, 2008, at 6:32 PM, bobhaugen wrote: > > That was going to be my next question: what is the reason for the best > > practice, vs what Fernando did?
> > If I understand what you just wrote correctly, what Fernando did is > > perfectly fine. But it wd be bad practice to do a svn checkout and > > then start hacking at basic_project or complete_project in place, on > > the checked out version.
> > Correct?
> Well, I think we're getting outside the realm of what Pinax should > suggest and what comes down to just the developers preference > regarding svn.
> If you export rather than checkout, you won't get new updates. If you > checkout and edit in place, your changes may clash with upstream > changes (and you'll have to resolve the merge conflicts). If you > checkout and copy out the project (being careful to delete the .svn > directories in the copy) you won't get updates *for those files* but > will for everything else.
> It all comes down to how you want to develop and how important the > latest pinax changes are to you.
On Thu, Oct 30, 2008 at 4:46 PM, Brian Rosner <bros...@gmail.com> wrote: > Yeah having PINAX_ROOT in one place seems to be right direction here. > I am still not 100% sure how this will be done yet. I have a use case > on the TWiD codebase as I build it around Pinax so I will be thinking > about this.
Just to let everyone know that as of revision 1184 PINAX_ROOT is now located in your settings. It can be changed in you local_settings.py making things much more reusable.
On Thu, Oct 30, 2008 at 6:34 PM, Brian Rosner <bros...@gmail.com> wrote: > On Thu, Oct 30, 2008 at 4:46 PM, Brian Rosner <bros...@gmail.com> wrote: >> Yeah having PINAX_ROOT in one place seems to be right direction here. >> I am still not 100% sure how this will be done yet. I have a use case >> on the TWiD codebase as I build it around Pinax so I will be thinking >> about this.
> Just to let everyone know that as of revision 1184 PINAX_ROOT is now > located in your settings. It can be changed in you local_settings.py > making things much more reusable.
Ugh, I should have given more information. Check out these documents now:
Specifically the deployment docs should how it is used. I would also recommend that if you have copied out a project to update your manage.py (if you are running trunk, not 0.5.0 otherwise you would need to uprgade to trunk to get this change.)
This certainly falls under the umbrella of personal preference, but I
generally like to export the project outside of the SVN checkout
directory due to the fact that SVN will always list that new directory
as an untracked file. If you accidentally check it in, and don't have
commit access, svn complains loudly in my experience. (This behavior
of loud complaints may have changed, but it left a bad enough taste in
my mouth to not do it again.) The nice thing, as brosner has pointed
out, is that now there's a single setting in settings.py (PINAX_ROOT)
which ensures that all of the relevant scripts know where Pinax is
located.
This is has been a useful and enlightening discussion (for me,
anyway).
I no longer feel the need for an example, especially with brosner's
last improvement.
But I do think the line in the Customization doc that says:
"Copy that project into a directory outside of the subversion
checkout."
should be changed to:
"Export that project into a directory outside of the subversion
checkout."
Or, if you prefer, export if you are working with a subversion
checkout, or copy if you downloaded an official release.
> This is has been a useful and enlightening discussion (for me, > anyway).
> I no longer feel the need for an example, especially with brosner's > last improvement.
> But I do think the line in the Customization doc that says: > "Copy that project into a directory outside of the subversion > checkout." > should be changed to: > "Export that project into a directory outside of the subversion > checkout."
> Or, if you prefer, export if you are working with a subversion > checkout, or copy if you downloaded an official release.
> But I do think the line in the Customization doc that says: > "Copy that project into a directory outside of the subversion > checkout." > should be changed to: > "Export that project into a directory outside of the subversion > checkout."
I think the "copy" notion is more in line with the concept of downloadable "releases" where you get a package. So there is no Subversion working copy to "export" from.
Maybe if people are using Subversion to get the edge version they are in charge of their own versioning strategy. In that case, a copy probably won't work because you can't just commit your website back into Pinax's repository...
|
