Re: OSHIP & Python 2.5
on 08/26/2008 04:42 PM Tim Cook wrote: > On Mon, 2008-08-25 at 22:33 +0200, Roger Erens wrote: > > >> In the current installation for linux page >> (http://www.openehr.org/wiki/display/dev/OSHIP+Installation+-+Linux >> ) I >> have the following remarks: >> >> 1) if you advise to create a directory called .buildout, it would be >> more consistent to have as eggs-directory >> /home/tim/.buildout/buildout-eggs instead of /home/tim/buildout-eggs. >> > > Hmmm, not sure what you mean here. My suggestion (taken from the > buildout and zopeproject instructions) was to create a directory > called .buildout in your home directory with the file default.cfg in > order to tell buildout where to store eggs that may be reused across > many projects. Of course I did say to put: > > [buildout] > eggs-directory=/home/tim/buildout-eggs > > inside default.cfg (per above instructions) since this would seem to > be > consistent with other buildout based projects. Using the '.' leading > directory names is pretty much a standard for configuration > directories/files. So you could easily put: > > [buildout] > eggs-directory=/home/tim/.buildout/buildout-eggs > > in default.cfg but then .buildout is no longer just a configuration > directory. Your choice though. > :-) I was taught from a different reference (Professional Plone Development by Martin Aspeli) that used the leading '.' directory name. BTW, .svn directories also contain more than just configuration info. > ... >> 4) maybe it's interesting to note that executing 'oship-ctl fg' from >> within the ~/sandbox/oship/bin directory fails because of inability >> to >> find zdaemon.conf. The server should be started from within the >> ~/sandbox/oship directory. >> > > > Also true. That is why the instructions leave you in the oship > directory and say to execute: $bin/oship-ctl fg > If you think an explanation is needed then it can be added. > I used to think that executables in a 'bin' directory could be invoked from any cwd. That's why I didn't bother at first to follow your instruction literally. The explanation seems to be that the command doesn't know about a configuration directory (Ha! We touch upon the first point above again!) so it expects to find the .conf file in the directory from where it was invoked. > > >> 5) finally, I wouldn't use the name 'sandbox' for the virtual >> environment. Developers will probably have multiple virtual >> environments >> created, and 'sandbox' is not very specific. I'd choose something >> like >> 'oshipenv'. >> >> > > True to some extent. But it is unlikely that developers will have > more > than one virtual environment for each version of Python that they wish > to work with. For example you may want a virtual environment for > Python2.4,Python2.5,Python2.6 and Python3. But each project based on > each version of Python would be included under that virtualenv. > Something like: > > sandbox2.5 - > oship > proj1 > proj2 > > sandbox2.6 - > oship > proj1 > > etc. > > This lets you reuse consistent environments. > This was already answered by Raphael. Maybe you _could_ end up with a use-case he describes, for example when you want to compare the performance of two versions of a library > ... > > >> I didn't get further in the Guide/Tour. >> > > We should probably delete the usage guide and combine the Linux and > Windows install guides into one document that would include the basic > parts of the usage guide. > > Also, the documents that are currently in the oship/src/oship/docs > directory are completely out of date. The management of the > installation text is completely out of sync. I would like to say that > the document oship/src/oship/docs/Installation.txt is the 'source' > information and then I could easily copy/paste it to the wiki page. > > Roger, since you have SVN access would you please update the > Installation.txt file along these lines? > Sure. > Alessandro currently has a problem with Windows installation that we > have not tracked down yet so the Installation.txt file should say > something to the effect that Windows install instructions are coming > soon. > > I can then do the copy/paste to the wiki and the wiki will always be > secondary to the Installation.txt file (as it should be). > On the wiki, I'd rather just put a link to the installation document in the svn repository. Having a wiki invites people to discuss the document there, while you stated that you'd like discussions wrt the docs to take place on this mailing list. Best regards, Roger _______________________________________________ ref_impl_python mailing list ref_impl_python@openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/ref_impl_python