What I meant to say is that 3) is, to me, the right answer. a) If it's a general library, it belongs in your installed libraries, not in your application's source tree. b) But since it's your library to maintain, you can still keep it around as an editable, live piece of code.
The above posted workflow gives you the tools to fulfill the requirements of 3a and 3b. J On Tue, May 6, 2014 at 11:16 AM, Javier Candeira <[email protected]> wrote: > 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
