Resending to the list. Noon: note I've added some clarifications over what I sent you by mistake.
On Tue, May 6, 2014 at 1:31 PM, Noon Silk <[email protected]> wrote: > Okay, so but then as part of the ci-build for this local internal project, > you are constantly testing the maybe-not-ever-changed version of the thing > you pip-installed? No, you aren't. It's an external library. If you require, say, Kenneth Reitz's Requests and install it in your virtualenv, you don't run its tests every time you commit something to your project. Here it's the same, except that the library is not Reitz's but yours, and it's still under some (mild) development. You only need to run the tests for your library when you modify your library. > Suppose also you make changes to this library, and they aren't accepted into > the master repo by the maintainer. How do you now share the changes you made > with the other developers of your internal thing? Pip can point to a particular commit, and in my example it does. So you can write on your repo's requirement.txt that commit that does a fix on your own repo. Once it's accepted in the mainline repo, you can modify your requirements.txt to point to the merge commit on the mailine repo. > Am I understanding right > in that they can't get the changes, because the changes will be contained The changes are contained in a git commit, so you can put that in your requirements.txt and ask everyone to update (or have the update in a git hook). > only in a pending pull request? (i.e. for this to work, you'd need to work > from a fork of the common library, and basically always merge in pull If it's not your library, yes. If you are the main author, you work from a checkout of development tip, or your feature tip, or whatever. And your repo can be public or private. It's your project. > requests to the fork. This seems somehow a bit broken to me, I think [you > can't submit a set of changes that contain changes both in the common > library and the internal libraryre as a single set, they must be a separate] I don't understand the difference between the common library and the internal one. Git is truly distributed. You can keep a private branch whose tracking remote is your private repo, and a main branch whose tracking remote is the public repo. I do that with my Ansible development: my branches track my own repo, so I can git push by default, but devel tracks the devel branch on upstream ansible repo, so I can git pull and see what's been done. The people in your team install from your requirements.txt, and the pip -e line on that one should have a release tag or a commit hash, not a branch name. J > On Tue, May 6, 2014 at 11:38 AM, Javier Candeira <[email protected]> > wrote: >> >> 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 > > > > > -- > 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
