Suggestion: example of the recommended customization setup

[bobhaugen]

http://pinaxproject.com/docs/0.5.0/customization.html says:

# 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?

[greg newman]

Unless I'm missing the context of your statement, the basic_project
and custom_project are examples of this.

Yes, best to checkout from svn then copy the project.

greg newman
http://20seven.org

[bobhaugen]

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?

But if I say (for example):
svn export http://svn.pinaxproject.com/pinax/trunk/projects/basic_project
pinax_basic_project

I get the basic project without any svn links, ready to stash in my
own repository.

Does that seem correct to you? Or am I missing something?

[James Tauber]

On Oct 29, 2008, at 2:54 PM, bobhaugen wrote:

> Also, isn't it best to do an export from svn of the project to start
> with, instead of copying from a Pinax checkout?

Yeah probably. Not even sure if the doc should talk about svn checkout
-- it's irrelevant if you download a release.

James

[bobhaugen]

True. But if I want (for example) django-schedule, I need to keep
with trunk, or a branch, or whatever. Correct?

And I still think the example customized setup is a good idea...

When I get one working and posted, I'll point to it here.

[Nikos Delibaltadakis]

I think this series of articles give some answers:
http://fernandoacorreia.wordpress.com/2008/10/22/exploring-pinax-part-1/

2008/10/29 bobhaugen <bob.h...@gmail.com>

--
Nikos Delibaltadakis

[bobhaugen]

On Oct 29, 3:49 pm, "Nikos Delibaltadakis" <delini...@gmail.com>
wrote:

> I think this series of articles give some answers:http://fernandoacorreia.wordpress.com/2008/10/22/exploring-pinax-part-1/

Nikos, thanks.

It's a helpful series of articles, but does not follow the best
practices from the Pinax doc (quoted in the first post in this
thread).

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.

[Fernando Correia]

2008/10/30 bobhaugen <bob.h...@gmail.com>:

> Fernando does do the export, but puts his new project *inside* the
> subversion checkout.

Thanks for the tip, I will correct the article.

Incidentally, I agree that you should export from svn, not copy the
checked out directory.

[bobhaugen]

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.

[Brian Rosner]

On Thu, Oct 30, 2008 at 8:56 AM, bobhaugen <bob.h...@gmail.com> wrote:
>
> I assume the change to *.wsgi will be similar, but not nearly ready to
> deploy yet.

Yes, you are correct. You just need to adjust PINAX_ROOT in the WSGI
file and you should be set :)

--
Brian Rosner
http://oebfare.com

[James Tauber]

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.

Note that with the change to the .wsgi and manage.py to factor out the
PINAX_ROOT, you should just need to change that.

James

[Fernando Correia]

2008/10/30 James Tauber <jta...@jtauber.com>:

> 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.

http://fernandoacorreia.wordpress.com/2008/10/22/exploring-pinax-part-1/

Cheers.

[bobhaugen]

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.

[Fernando Correia]

2008/10/30 bobhaugen <bob.h...@gmail.com>:

> 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).

[Brian Rosner]

On Thu, Oct 30, 2008 at 4:32 PM, bobhaugen <bob.h...@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.

[James Tauber]

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.

James

[Adam Nelson]

Not to beat a dead horse, but I think there's some confusion:

[Original way on Fernando's site using 'varud' which is my project name]

$ svn co https://svn.pinaxproject.com/pinax pinax/
$ cd pinax/projects/
$ svn export complete_project/ varud/
$ cd ../../
$ svn up

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.

Either way works though.

[derek73]

Here's what I did to migrate my previously started project into pinax:

$ svn co https://svn.pinaxproject.com/pinax pinax/
$ cd pinax/projects/

$ svn export complete_project/ myproject/
$ cd myproject
$ svn co http://svn.mysite.com/repos/myproject/trunk .
$ svn add *
$ svn ci -m "creating myproject as export of complete_project rev
1171"
$ svn info # -> http://svn.mysite.com/repos/
$ cd ../../
$ svn info # -> https://svn.pinaxproject.com/pinax
$ svn up
$ cd ..
$ svn cp mypreviousproject/mycustomapp pinax/projects/myproject/
mycustomapp/
$ svn ci -m "adding mycustomapp with svn history"

[derek73]

On Oct 30, 5:16 pm, derek73 <dere...@gmail.com> wrote:
> $ svn co http://svn.mysite.com/repos/myproject/trunk.

sorry, actually this was an empty branch in my repos, not trunk.

[Brian Rosner]

On Thu, Oct 30, 2008 at 4:46 PM, Brian Rosner <bro...@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.

[Brian Rosner]

Ugh, I should have given more information. Check out these documents now:

http://pinaxproject.com/docs/trunk/deployment.html
http://pinaxproject.com/docs/trunk/customization.html

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.)

http://svn.pinaxproject.com/pinax/trunk/projects/complete_project/manage.py

[Eric Florenzano]

> $ svn cohttps://svn.pinaxproject.com/pinaxpinax/

> $ cd pinax/projects/
> $ svn export complete_project/ varud/
> $ cd ../../
> $ svn up

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.

-Eric Florenzano

[bobhaugen]

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.

[greg newman]

Personally i just copy outside and have the alias below in my
bash_profile that I run to clear out the svn dirs.

alias svnclear='find . -name .svn -print0 | xargs -0 rm -rf' # removes
all .svn folders from directory recursively

greg newman
http://20seven.org

[Fernando Correia]

2008/10/31 bobhaugen <bob.h...@gmail.com>:

> 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...

[Fernando Correia]

2008/10/31 greg newman <gr...@20seven.org>:

>
> Personally i just copy outside and have the alias below in my
> bash_profile that I run to clear out the svn dirs.
>
> alias svnclear='find . -name .svn -print0 | xargs -0 rm -rf' # removes
> all .svn folders from directory recursively

Man, svn export does this more cleanly...

[James Tauber]

Right, this is what I was trying to get at earlier. Should the
documentation be for the person downloading a tar.gz or for the person
checking out of svn? I think the primary audience really should be the
former.

Either way, I agree the customization doc needs to be changed :-)

James

[Fernando Correia]

2008/10/31 James Tauber <jta...@jtauber.com>:

> Right, this is what I was trying to get at earlier. Should the
> documentation be for the person downloading a tar.gz or for the person
> checking out of svn? I think the primary audience really should be the
> former.

I think the main doc should be based on the concept of releases, and
there could be an additional doc about running "edge", or whatever
people call it nowadays.

[derek73]

You're right, since the parent directories to my project are working
copies of another repository, if I ever did go up a directory and try
an svn ci or something it would give me a permissions error rather
than committing my changes to pinax trunk (thankfully). But the only
reason I'm ever in that directory is to update it. My project showing
up in my pinax working copy as an unversioned directory is never a
problem in practice. The same thing happens if you symlink your
project into the pinax project dir.