What I do: pip has an option, -e, which installs an "editable" version of a library
and you can pip install from a repository, like so: pip -e git+https://github.com/candeira/ansible.git@a002a249731ca7c7dd35d0d4f79108b632fde2dd#egg=ansible-dev Now my development virtualenv is running this particular library from its src/ansible/ directory, an editable git repo which I can modify, checkout branches and, in this case, since Ansible is not my project, make pull requests with bugfixes and features. If it were mine, I could publish the appropriate branch to git master and to the cheese shop. The workflow is still not set in stone, but works quite well for me. J On Tue, May 6, 2014 at 10:54 AM, Peter Davis <[email protected]> wrote: > Hi, > > Sounds like you probably have two libraries, a public and private one. I > would fork the latter (private) from the former (public) and put it on a > private online repository. Then you can install the private version using > pip’s git+ssh functionality. > > Any changes you make to private library could be potentially pushed back > upstream to the public one. > > Peter > > On 6 May 2014, at 10:45 am, Noon Silk <[email protected]> wrote: > > Hello, > > Suppose you are writing some code. Suppose one day, you decide "hey, this > bit of code is sufficiently common, I'll make it into an independent > library!", so you do that, you publish it on github and bask in the > green-ness of your travis build. > > Now suppose you want to use this common library in your own "main" app > somehow. You have a few options for including it: > > 1) Local copy in your repo either as: > - Subrepo pointing at source, > - Subrepo pointing at your own fork (note: in the above case you might > want to modify the public library in some way that is not compatible with > the public goals, but more of a specific thing for your own internal stuff.) > > 2) Local copy as symlink to a clone or fork as above > > 3) Completely independent thing that you pip install > > What option do you take? (I've probably missed other better ideas.) I have > some feelings about this, but I'm not entirely sure which way is the best > way yet, and am interested in opinions, and maybe more interested in *what > you actually do*. > > Suppose that the common library is changing "somewhat often"; maybe once a > month or so. Let's suppose you'd prefer to move functionality into that > library, but you can forsee needing to modify it for your own needs (well, > if so, does this just flat-out eliminate option 3?). > > Note, I suppose, in the options where you might accidentally modify it > (when you have a local copy) you probably need to be running the tests. > > -- > Noon Silk > > Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/ > > "Every morning when I wake up, I experience an exquisite joy — the joy > of being this signature." > _______________________________________________ > melbourne-pug mailing list > [email protected] > https://mail.python.org/mailman/listinfo/melbourne-pug > > > > _______________________________________________ > melbourne-pug mailing list > [email protected] > https://mail.python.org/mailman/listinfo/melbourne-pug > _______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
