Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #27146 > unrolled thread
| Started by | Jean-Michel Pichavant <jeanmichel@sequans.com> |
|---|---|
| First post | 2012-08-16 10:49 +0200 |
| Last post | 2012-08-16 10:49 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Sharing code between different projects? Jean-Michel Pichavant <jeanmichel@sequans.com> - 2012-08-16 10:49 +0200
| From | Jean-Michel Pichavant <jeanmichel@sequans.com> |
|---|---|
| Date | 2012-08-16 10:49 +0200 |
| Subject | Re: Sharing code between different projects? |
| Message-ID | <mailman.3347.1345106999.4697.python-list@python.org> |
andrea crotti wrote:
> 2012/8/14 Cameron Simpson <cs@zip.com.au>:
>
>> Having just skimmed this thread, one thing I haven't quite seen suggested is
>> this:
>>
>> Really do make a third "utilities" project, and treat "the project" and
>> "deploy" as separate notions. So to actually run/deploy project A's code
>> you'd have a short script that copied project A and the utilities project
>> code into a tree and ran off that. Or even a simple process/script to
>> update the copy of "utilities" in "project A"'s area.
>>
>> So you don't "share" code on an even handed basis but import the
>> "utilities" library into each project as needed.
>>
>> I do this (one my own very small scale) in one of two ways:
>>
>> - as needed, copy the desired revision of utilities into the project's
>> library space and do perforce's equivalent of Mercurial's addremove
>> on that library tree (comment "update utilities to revision X").
>>
>> - keep a perforce work area for the utilities in your project A area,
>> where your working project A can hook into it with a symlink or some
>> deploy/copy procedure as suggested above.
>> With this latter one you can push back into the utilities library
>> from your "live" project, because you have a real checkout. So:
>>
>> projectAdir
>> projectA-perforce-checkout
>> utilities-perforce-checkout
>> projectBdir
>> projectB-perforce-checkout
>> utilities-perforce-checkout
>>
>>
>
> Thanks, is more or less what I was going to do.. But I would not use
> symlinks and similar things, because then every user should set it up
> accordingly.
>
> Potentially we could instead use the perforce API to change the
> workspace mappings at run-time, and thus "force" perforce to checkout
> the files in the right place..
>
> There is still the problem that people should checkout things from two
> places all the time instead of one..
>
>
SVN allows to define external dependencies, where one repository will
actually checkout another one at a specific version. If SVN does it, I
guess any decent SCM also provide such feature.
Assuming our project is named 'common', and you have 2 projects A and B :
A
- common@rev1
B
- common@rev2
Project A references the lib as "A.common", B as "B.common". You need to
be extra carefull to never reference common as 'common' in any place.
JM
Back to top | Article view | comp.lang.python
csiph-web