Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'needed,': 0.05; 'repository': 0.05; 'revision': 0.05; 'svn': 0.05; 'feature.': 0.07; 'subject:code': 0.07; 'api': 0.09; 'project"': 0.09; 'symlink': 0.09; 'thread,': 0.09; 'cc:addr:python-list': 0.10; 'accordingly.': 0.13; 'library': 0.15; 'decent': 0.16; 'perforce': 0.16; 'simpson': 0.16; 'subject:between': 0.16; 'subject:projects': 0.16; 'ways:': 0.16; 'workspace': 0.16; 'wrote:': 0.17; 'copied': 0.17; 'version.': 0.17; 'thanks,': 0.18; 'define': 0.20; 'equivalent': 0.20; 'suggested': 0.20; 'import': 0.21; 'assuming': 0.22; 'latter': 0.22; 'needed.': 0.23; 'references': 0.23; 'this:': 0.23; "haven't": 0.23; 'project,': 0.24; 'thus': 0.24; 'external': 0.24; 'cc:2**1': 0.24; 'script': 0.24; 'allows': 0.25; 'cc:addr:python.org': 0.25; 'header:In- Reply-To:1': 0.25; 'header:User-Agent:1': 0.26; 'common': 0.26; 'guess': 0.27; 'separate': 0.27; 'tree': 0.27; 'things,': 0.29; '"the': 0.29; 'that.': 0.30; 'push': 0.30; 'code': 0.31; 'could': 0.32; 'problem': 0.33; 'another': 0.33; 'project': 0.34; 'third': 0.34; 'subject:?': 0.35; 'similar': 0.35; 'there': 0.35; 'really': 0.36; 'skip:u 20': 0.36; 'but': 0.36; 'should': 0.36; 'skip:p 20': 0.36; 'does': 0.37; 'two': 0.37; 'quite': 0.37; 'subject:: ': 0.38; 'files': 0.38; 'some': 0.38; 'things': 0.38; 'instead': 0.39; 'space': 0.39; 'short': 0.39; 'where': 0.40; 'your': 0.60; 'real': 0.61; 'places': 0.61; 'procedure': 0.61; 'received:194': 0.61; 'back': 0.62; 'provide': 0.62; 'more': 0.63; 'our': 0.65; 'treat': 0.65; 'potentially': 0.66; 'andrea': 0.84 X-IronPort-AV: E=Sophos;i="4.77,778,1336341600"; d="scan'208";a="657526" X-Virus-Scanned: amavisd-new at zimbra.sequans.com Date: Thu, 16 Aug 2012 10:49:42 +0200 From: Jean-Michel Pichavant User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) MIME-Version: 1.0 To: andrea crotti Subject: Re: Sharing code between different projects? References: <20120814215118.GA19167@cskk.homeip.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: python-list X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 65 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1345106999 news.xs4all.nl 6913 [2001:888:2000:d::a6]:58253 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:27146 andrea crotti wrote: > 2012/8/14 Cameron Simpson : > >> 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