Forums

virtualenv :: PAW specifics

Is there a post/tutorial on how virtualenv is set up to work at PAW? It's wonderful because pip is an integral part of that package -- and "pip freeze" is useful to replicate the project dependencies.

I noticed /usr/local/bin/virtualenv is available. My scripts, however, require a direct link to virtualenv.py -- so does anybody know its exact location?

Sure, I could just upload my private copy, but I figure PAW always updates theirs to the latest version, and there might be special paths and symlinks tailored for this particular system :-) i.e. what are the gotchas, if any. Thanks!

Hi there, sorry no-one replied sooner.

We don't do anything particularly special with virtualenv, it's installed in a reasonably default location:

$ python -c "import virtualenv; print virtualenv.__file__"
/usr/local/lib/python2.7/site-packages/virtualenv-1.8.2-py2.7.egg/virtualenv.pyc

Apart from that, there's a slight trick you need to use for your wsgi.py to get virtualenvs working, cf this discussion

We're planning on updating the FAQ with a bit more info...

Hey, its been a year and info on using Virtualenv is still a bit skimpy in the FAQ. For example, I can't re-find the link to a tutorial on using virtualenv to install a Django1.4 - which I was able to easily adapt to django1.5.

Consider this an upvote!

Or a reference manual for the version your using....

@rcooke, is this what you were looking for? Last week we were just discussing how much good stuff is locked in the forums and that we should have a place where it is easier to find. We're thinking of setting up a wiki where we can promote useful stuff from the forums and aggregate links to things like the virtualenvdemo.

I think a wiki is an excellent idea, although perhaps with some access controls instead of being entirely public, at least initially. Might be handy to use Markdown syntax for it to make transplanting forum posts easier, but the only Python wiki engine using Markdown I found was this one and it seems to have been abandoned a couple of years ago. Also, it's worth being aware that Markdown's syntax is a little limited for complex formatting (it's not as flexible as, say, the markup for Dokuwiki or Mediawiki for example, but those are both written in the dreaded PHP - that said, I use Dokuwiki personally and it's a perfectly competent engine).

That said, it should be fine for straightforward wiki pages and the Python markdown module has an extension which supports most of the markdown extra syntax extensions, which make it a lot more capable.

Probably writing a simple wiki engine for the site would have benefits, such as better forum integration (it would be fab to have a simple "migrate to wiki" option on each post), but is almost certainly more work.

I'm actually looking at wikis today. Looks like there are a nice set of Django-based wikis and I'm hoping I can just drop one in (heh - when has that ever been true?)

Oh Glenn, why so cynical? It's almost as if you've done this sort of thing before... (^_^)

If the wiki supports hierarchical namespaces (which are handy, but not essential) then I suggest checking if it makes it really easy to move pages around to different namespaces. Otherwise the self-organising nature of wiki becomes somewhat harder. It's less of an issue for flat wikis, although these do require people to pick ReallyDescriptivePageNamesThatAreUnlikelyToClashInTheFuture.

Dokuwiki, for example, supports namespaces really well, but moving pages is a pain (basically a manual cut-and-paste job and the history of the page isn't copied across). This is fine for a tightly-controlled wiki, but if you're going to allow people to create whatever pages they fancy then things can become disorganised and this makes content discovery difficult. I'm afraid I don't agree with Google's "search is all you need" mentality when it comes to documentation because often it's hard to guess appropriate keywords until you know what you're looking for.

Of course, the principle is that the users of the wiki will write their own contents and index pages on demand, but again, this behaviour doesn't tend to develop totally organically, it needs a little encouragement.

Anyway, just some things to bear in mind. Picking a wiki engine always seems to involve compromising somewhere, so it's probably not worth being too picky. Unfortunately I'm the picky sort... Good job it's not me doing the choosing! (^_^)

Glenn & Cartroo:

Is there a Django Wiki plugin? Or a TRAC plugin?

I've heard rumors....

I had a look through Django wiki plugins and found that there were a few, but none that fit our needs so I didn't try them. I used this grid for the initial filter. It may be useful to you.

Trac already has a wiki built in.

So I'm setting up a demo PAW site for a new client. I need TRAC and Django.

Would there happen to be a sample wsgi file for this? I hate starting from scratch....

oh crap. This is "rcooke" again. I told you we need to show user ID along the top of the Dashboard or something...

This is the demo account I setup for the client.

A few more of these and I might become totally Schizoid.

Just a note for anyone hitting this page from Google -- the conversation about getting Trac working continues over here

And here is a link to my working wsgi file to serve up Trac and Django.