Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #27146 > unrolled thread

Re: Sharing code between different projects?

Started byJean-Michel Pichavant <jeanmichel@sequans.com>
First post2012-08-16 10:49 +0200
Last post2012-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.


Contents

  Re: Sharing code between different projects? Jean-Michel Pichavant <jeanmichel@sequans.com> - 2012-08-16 10:49 +0200

#27146 — Re: Sharing code between different projects?

FromJean-Michel Pichavant <jeanmichel@sequans.com>
Date2012-08-16 10:49 +0200
SubjectRe: 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

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web