Log file Viewer
#pypa-dev logs for Monday the 30th of March, 2015
[01:41:26] <pmxbot> arfrever pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :
[02:27:38] <pmxbot> arfrever pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :
[18:23:38] <xafer> qwcode, it you have some time, https://github.com/pypa/pip/pull/2614 should be ready :)
[20:34:35] <lifeless> is there home dir isolation around the pip tests? e.g. does each test get a unique ~ ?
[21:19:01] <etcdctlftw> Is there any advice to work around broken relative local paths in pip requirement.txt files? http://stackoverflow.com/a/12921216
[21:22:33] <lifeless> [not being facetious - they are intended for local use, so should be locally editable]
[21:30:16] <carljm> etcdctlftw: That answer references a quite old pip version as "the current version of pip", so I wouldn't be surprised if the information there is outdated.
[21:30:29] <carljm> Have you tried the latest version of pip? What specific problem are you having with relative paths?
[21:32:43] <etcdctlftw> lifeless: I can edit the requirements.txt file no problem, my question is that I can't find a working method for referencing a local relative path for one of my eggs. carljm: pip --version gives 1.5.6.
[21:46:45] <lifeless> dstufft: have a look at my latest commit in https://github.com/pypa/pip/pull/2618
[21:52:15] <lifeless> dstufft: no, its so we have a place to put the wheels we're going to build in install
[21:52:39] <lifeless> dstufft: I figured we needed to be able to disable this, didn't think it was conceptually big enough to warrant its own option
[21:54:19] <dstufft> lifeless: yea that makes sense, I just wasn't sure about https://github.com/rbtcollins/pip/commit/77df2702c1b9856adead6aa9a00c59e3018cb820
[21:55:01] <lifeless> dstufft: particularly when it can lead to skew which this widely separated use could
[21:56:14] <dstufft> not yet, it's in my TODO list for today/tomorrow. This weekend I was super busy
[21:56:46] <dstufft> lifeless: yea, tying things into --no-cache-dir makes sense to me, we probably want to also disable it if --no-use-wheels is set too
[21:58:15] <dstufft> (that's another flag inside of pip from the 1.4 era when wheels were opt in, now it's used as an opt out of wheels)
[21:58:39] <etcdctlftw> lifeless: carljm: I upgraded to pip 6.0.8 and I still can't get relative local paths to work.
[21:58:59] <etcdctlftw> I have a child project (storing cross-app server configs, credentials etc) that is a git submodule inside my current project. In my requirement.txt, I've tried a few combinations:
[22:00:34] <dstufft> lifeless: i'm abit nervous about turning this on by default in the first version it exists in, but I'm not sure it's worth the overhead of yet another flag to opt in to it for one release, so honoring those two flags is probably good enough
[22:05:15] <sigmavirus24> dstufft: pretty sure at this point we should just totally remove support for relative file paths
[22:14:40] <etcdctlftw> sigmavirus24: hm. every tutorial I saw said file:blah not file://blah. I'll try the second one, thanks for the suggestion!
[22:18:13] <etcdctlftw> sigmavirus24: -e file://./externals/childproject#egg=my-child didn't work: Error [Errno 2] No such file or directory: '\\\\./externals/childproject' while executing command python setup.py egg_info
[22:20:44] <etcdctlftw> Similar message when trying file://externals/childproject: No such file or directory: '\\\\externals/childproject'
[22:22:30] <etcdctlftw> In my particular situation, do I really need the editable -e argument? (pardon my newbie python question....) Because I think I saw somewhere that relative paths work if the eggs aren't installed as editable.
[22:25:44] <etcdctlftw> sigmavirus24: I just started at a new company where they set up internal "projects" that are collections of configs that are shared between python and other languages, and these projects are configured as python eggs when used in a python project
[22:27:31] <etcdctlftw> sigmavirus24: lifeless: It's working fine because currently they have it hit the company github account using an ssh key. However, now I'm trying to deploy it to a clean environment that doesn't have the ssh key and therefore need to pre-clone those config projects into the current project's dir
[22:28:49] <sigmavirus24> If you're doing a deployment, why do you want the installations to be editable?
[22:29:18] <lifeless> if its a clean, isolated environment, I'd be giving it a devpi server or some such to point to
[22:29:32] <etcdctlftw> Because I want the devs to be able to check out this exact requirements.txt file and have it "just work"
[22:30:42] <sigmavirus24> etcdctlftw: currently anything installing from github shouldn't be installing as editable
[22:30:53] <sigmavirus24> so to preserve that behaviour, you shouldn't be installing from local sources as editable
[22:31:26] <etcdctlftw> lifeless: currently we do install from github. but I'm trying to change that because in the deploy environment (a docker container actually) I don't want to have to install the ssh jey
[22:33:21] <etcdctlftw> lifeless: I'm trying to have jenkins check out the main project with all child config projects in an "./externals" subdir, then in docker I run "pip install -r requirements.txt"
[22:35:25] <lifeless> but if you want to do that, and you want access to privileged data within the container without, you need to cache it somehow
[22:35:49] <etcdctlftw> that's actually exactly what I'm going for. step 1 is checkout, step 2 is build, step 3 is run.
[22:35:58] <tomprince> etcdctlftw: Have you seen https://glyph.twistedmatrix.com/2015/03/docker-deploy-double-dutch.html ?
[22:37:02] <lifeless> etcdctlftw: well, pip install is build, but you said you're doing that in the container
[22:38:30] <etcdctlftw> lifeless: sorry for misrepresenting, when I said "in docker I run pip install -r requirements.txt" I meant in the dockerfile, so during the *building* of the container.
[22:39:05] <etcdctlftw> tomprince: thank for the link! is this basically a tutorial to do what lifeless is suggesting with pip wheel?
[22:42:07] <etcdctlftw> those child projects on the company github are private repos, so I couldn't ssh to them in my dockerfile unless I first import the private key... unless I'm misunderstanding you?
[22:43:21] <lifeless> etcdctlftw: SSH agents allow you to access a private key without having it within a file tree
[22:46:23] <etcdctlftw> lifeless: That's an interesting trick, I never thought of that. Just to clarify, you're suggesting to use ssh-agent on the Jenkins host so that when the docker daemon that it starts tries to ssh into the company github (inside the dockerfile), ssh-agent will do key forwarding?
[22:47:00] <lifeless> I'm suggesting to use ssh-agent within the Jenkins build process that builds the container image.
[22:47:16] <lifeless> Because jenkins already has either the key or a running agent, letting it get at github.
[22:49:33] <etcdctlftw> Have you seen this work before? When I include a line like "RUN ssh ubuntu@server" inside my dockerfile, the docker daemon building this dockerfile will use the ssh-agent configured on the host?