«

2012/8/13 Rob Day <>:
> I'd just create a module - called shared_utils.py or similar - and import
> that in both projects. It might be a bit messy if there's no 'unifying
> theme' to the module - but surely it'd be a lot less messy than your
> TempDirectory class, and anyone else who knows Python will understand
> 'import shared_utils' much more easily.
>
> I realise you might not want to say, but if you could give some idea what
> sort of projects these are, and what sorts of code you're trying to share,
> it might make things a bit clearer.
>
> I'm not really sure what your concerns about 'versioning and how to link
> different pieces together' are - what d you think could go wrong here?
>

It's actually not so simple..

Because the two projects live in different parts of the repository
with different people allowed to work on them, and they have to run on
different machines..

In plus I'm using perforce which doesn't have any svn:externals-like
thing as far as I know.. The thing I should do probably is to set up
workspace (which contains *absolute* paths of the machines) with the
right setting to make module available in the right position.

Second problem is that one of the two projects has a quite insane
requirement, which is to be able to re-run itself on a specific
version depending on a value fetched from the database.

This becomes harder if divide code around, but in theory I can use the
changeset number which is like a SVN revision so this should be fine.

The third problem is that from the moment is not just me using these
things, how can I be sure that changing something will not break
someone else code?

I have unit tests on both projects plus the tests for the utils, but
as soon as I separate them it becomes harder to test everything..

So well everything can have a solution probably, I just hope it's
worth the effort..

Another thing which would be quite cool might be a import hook which
fetches things from the repository when needed, with a simple
bootstrap script for every project to be able to use this feature, but
it only makes sense if I need this kind of feature in many projects.

> In plus I'm using perforce which doesn't have any svn:externals-like
You can probably use views to this (http://www.perforce.com/perforce/r12...f/o.views.html).

> Second problem is that one of the two projects has a quite insane
> requirement, which is to be able to re-run itself on a specific
> version depending on a value fetched from the database.
You can probably play with PYTHONPATH to do that.

> The third problem is that from the moment is not just me using these
> things, how can I be sure that changing something will not break
> someone else code?
That's always a problem with libraries you distribute, no matter what is the mechanism for distribution.

If you go the views/link way. You can link to tags instead of trunk (or the perforce equivalent) and then client can still to know "good" version. If you go the PyPi route, you can specify package version in setup.py dependencies (foo==0.10.2)

> In plus I'm using perforce which doesn't have any svn:externals-like
You can probably use views to this (http://www.perforce.com/perforce/r12...f/o.views.html).

> Second problem is that one of the two projects has a quite insane
> requirement, which is to be able to re-run itself on a specific
> version depending on a value fetched from the database.
You can probably play with PYTHONPATH to do that.

> The third problem is that from the moment is not just me using these
> things, how can I be sure that changing something will not break
> someone else code?
That's always a problem with libraries you distribute, no matter what is the mechanism for distribution.

If you go the views/link way. You can link to tags instead of trunk (or the perforce equivalent) and then client can still to know "good" version. If you go the PyPi route, you can specify package version in setup.py dependencies (foo==0.10.2)