*** mordred has quit IRC | 02:42 | |
*** mordred has joined #openstack-dib | 02:44 | |
*** pmannidi has quit IRC | 02:44 | |
*** pmannidi has joined #openstack-dib | 02:48 | |
*** chhavi__ has joined #openstack-dib | 04:25 | |
openstackgerrit | Ian Wienand proposed openstack/diskimage-builder master: Revert "Dont install python-pip for py3k" https://review.openstack.org/532395 | 04:50 |
---|---|---|
*** pmannidi has quit IRC | 07:21 | |
*** hashar has joined #openstack-dib | 08:19 | |
*** owalsh has quit IRC | 09:09 | |
*** owalsh has joined #openstack-dib | 09:10 | |
*** andreas_s has joined #openstack-dib | 09:30 | |
*** hashar is now known as hasharAway | 10:51 | |
*** andreas_s has quit IRC | 11:08 | |
*** andreas_s has joined #openstack-dib | 11:09 | |
*** andreas_s has quit IRC | 11:23 | |
*** andreas_s has joined #openstack-dib | 11:23 | |
*** chhavi__ has quit IRC | 11:35 | |
*** andreas_s has quit IRC | 11:37 | |
*** andreas_s has joined #openstack-dib | 11:38 | |
*** andreas_s has quit IRC | 11:48 | |
*** andreas_s has joined #openstack-dib | 11:49 | |
*** vmlinuz has joined #openstack-dib | 11:56 | |
*** vmlinuz has quit IRC | 12:26 | |
*** vmlinuz has joined #openstack-dib | 12:38 | |
*** vmlinuz has joined #openstack-dib | 12:38 | |
*** andreas_s has quit IRC | 13:27 | |
*** andreas_s has joined #openstack-dib | 13:32 | |
*** andreas_s has quit IRC | 13:37 | |
*** andreas_s has joined #openstack-dib | 13:38 | |
*** andreas_s has quit IRC | 13:40 | |
*** andreas_s has joined #openstack-dib | 13:40 | |
*** andreas__ has joined #openstack-dib | 13:41 | |
*** andreas_s has quit IRC | 13:45 | |
*** ameeda_ has joined #openstack-dib | 13:46 | |
*** ameeda_ has quit IRC | 14:13 | |
*** dhill_ has quit IRC | 14:27 | |
*** dhill_ has joined #openstack-dib | 14:27 | |
*** chhavi__ has joined #openstack-dib | 14:34 | |
*** openstackgerrit has quit IRC | 15:01 | |
*** tdriscoll has joined #openstack-dib | 16:04 | |
*** andreas__ has quit IRC | 16:30 | |
*** andreas_s has joined #openstack-dib | 16:32 | |
*** andreas__ has joined #openstack-dib | 16:33 | |
*** andreas_s has quit IRC | 16:36 | |
*** andreas__ has quit IRC | 16:41 | |
*** clarkb has quit IRC | 16:53 | |
greghaynes | ianw: hey, on ^ I think the the way to go might be add support for DIB_PYTHON_VERSION="2,3", which i guess is what infra would want | 17:14 |
greghaynes | surprsied it broke infra since I thought they install all the deps explicitly, but probably shouldnt break back compat anyhow | 17:15 |
*** openstack has joined #openstack-dib | 18:32 | |
*** ChanServ sets mode: +o openstack | 18:32 | |
ianw | greghaynes: i guess it exposes the job should probably install deps | 20:16 |
ianw | "2,3" might be ok ... i think my preference for a point release would be retain the old behaviour, and then consider larger changes | 20:17 |
greghaynes | ianw: yep, what do you think of a patch that adds support for 2,3 and makes that the default? | 20:20 |
greghaynes | it gets odd if someone is explicitly setting DIB_PYTHON_VERSION=3 or similiar as it would be a behavior change there... | 20:20 |
greghaynes | so if we want to be super pedantic I could put in a deal for -2,3 to special case no python2 | 20:21 |
ianw | is this a special case? one of the problems here is you can get yourself so tangled up with pip installs of these things | 20:26 |
ianw | depending on what order you get different binaries in the path, which then creates different virtualenvs etc | 20:26 |
ianw | also, the fedora path hasn't obeyed this either | 20:26 |
greghaynes | I kind of think the place we want to be is having py3k only be the default since thats what various upstream distros are doing | 20:27 |
greghaynes | so I dont think it a special case | 20:27 |
greghaynes | but here it would be unless we did a major version bump due to backwards compat | 20:27 |
ianw | i agree with the sentiment | 20:32 |
ianw | DIB_PYTHON_VERSION hasn't really been about "don't bring in py2 packages", it was more "use this to do python things during the build" | 20:33 |
ianw | which is a sort of subtle difference | 20:33 |
ianw | so yeah, thinking on it a bit more, I'm not sure DIB_PYTHON_VERSION=2,3 makes that much sense | 20:34 |
ianw | maybe we need a specific flag for this element to disable python2 components | 20:34 |
ianw | (and for other elements to follow too i guess) | 20:34 |
ianw | although, maybe most other elements are happy just calling dib-python so, defacto, do things with the right python | 20:35 |
greghaynes | Those two things (what dib uses for python in build and what yuou end up with) are coupled which was the root cause of that var - you have to tell dib to use the same thing you want | 20:35 |
ianw | ... which kind of loops back to maybe this element is a special case | 20:35 |
greghaynes | its fine if what you want is a superset, but dib has to use something you want basically | 20:35 |
ianw | right, but it's just in this element we have all these ordering issues | 20:36 |
greghaynes | and yes thats the idea with dib-python - use that as the indirection layer so no one else needs to care (hopefully) | 20:36 |
greghaynes | yep | 20:36 |
ianw | wiping out the system packages, making sure /usr/bin/pip is a python2 version (when installing v3 pip overwrites that, etc) | 20:36 |
ianw | that's kind of the point of this element ... to make python2 & 3 pip/virtualenv live happy together | 20:37 |
ianw | for almost every other element, i'd image they just want to install their package based of dib-python version, where a strict 2/3 split is fine | 20:38 |
greghaynes | hrm, so if we go the route of making a separate element for pure python2 and python3 were going to have to mess with element-provides stuff | 20:39 |
greghaynes | because various things element-deps on pip-and-virtualenv | 20:39 |
greghaynes | actually, hrm, I think various things dont really want to use dib-python if youre installing a package, thats just if you want to run some python as part of a build | 20:41 |
greghaynes | because when youre installing something you generally want to be explicit about py3 vs py2 | 20:41 |
greghaynes | which also makes me think that if we go the route of splitting elements then you want to have element-provides for pip3, virtualenv3, pip2, virtualenv2 | 20:42 |
greghaynes | but then you get in to the thing I think you were talking about where the two versions of pip interact with each other | 20:43 |
greghaynes | I have to run and grab lunch, will think on it a bit though | 20:44 |
ianw | yeah, you want to end up with a consistent sane state as left in https://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/elements/pip-and-virtualenv/README.rst#n41 | 20:44 |
greghaynes | but im fine with reverting that patch, just trying to figure out a path forward afgter | 20:44 |
ianw | sure, yeah when i get a minute i just want to do some test builds before pushing | 20:45 |
ianw | so you're not really supposed to set DIB_PYTHON_VERSION, right, it's exported by dib-python | 20:45 |
ianw | maybe we need a different variable that handles 2 3 2,3 as suggested | 20:46 |
greghaynes | I think youre supposed to be able to set it to force dib to use a certain version | 20:46 |
ianw | to indicate to elements what versions of things they can try to install | 20:46 |
ianw | since it's in the environment, i think really it has to be considered an api for elements so a 2,3 change would be incompat? | 20:47 |
ianw | i guess setting it works, but it's not mentioned at all in https://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/elements/dib-python/README.rst what the implications of that are | 20:49 |
*** vmlinuz has quit IRC | 21:02 | |
*** hasharAway has quit IRC | 21:38 | |
*** chhavi__ has quit IRC | 21:41 | |
greghaynes | Yep thats what I was getting at with maybe making a special case for now. Something like "-2,3" that means 'no python2' and have a todo in there to change the behavior when a new major version bump happens to require 2,3 in order to get both | 21:50 |
ianw | i don't think we can directly do that, because the idea was you could do virtualenv -p python${DIB_PYTHON_VERSION} and get something sane | 22:17 |
greghaynes | where would you want to do that? | 22:28 |
ianw | greghaynes: do what, make a virtualenv as part of an element? | 23:38 |
greghaynes | ianw: specifically with dib_python_version. Cases like that I am thinking you actually wouldnt want to use DIB_PYTHON_VERSION since most things you isntall you know you want it specifically on python2 or 3 | 23:39 |
greghaynes | IOW maybe DIB_PYTHON_VERSION should be only for dib build time stuff and so a user can make sure dib doesnt require a different python than they want, for other cases just be explicit about python2 or python3 | 23:40 |
greghaynes | hrm, which makes me think your original thought about breaking it out in to separate elements might be the way to go... | 23:42 |
greghaynes | pip-and-virtualenv, I mean | 23:43 |
ianw | so I sort of see DIB_PYTHON_VERSION as a read-only value ... it's exported by dib-python just as a reference to what python version "dib-python" is. dib-python being the "system python" you want to use when using python in an element, to abstract away from python2/3 not being there | 23:44 |
greghaynes | the issue is we seem to have two use cases were going to need to support - installing both 2 and 3 and installing only 3 since thats upstream default | 23:45 |
greghaynes | so thre does need to be some way for a user to specify which | 23:45 |
greghaynes | id be fine using some other mechanism though... | 23:46 |
ianw | ok, but is that the role of dib-python? it doesn't actually *install* anything | 23:46 |
*** tdriscoll has quit IRC | 23:46 | |
greghaynes | dib-python I think is purely an indirection layer for things doing build time python work | 23:47 |
ianw | right, we agree on that :) | 23:47 |
greghaynes | so how crazy do you think itd be to make DIB_PYTHON_VERSION readonly as you say, then make pip-and-virtualenv2 and pip-and-virtualenv3, then have pip-and-virtualenv depend on both | 23:49 |
ianw | so we have slightly overloaded it however | 23:49 |
ianw | with dib_python_version in package installs? | 23:49 |
greghaynes | I dont understand | 23:50 |
greghaynes | I agree we have overloaded it, dont understand the package installs thing | 23:50 |
ianw | https://git.openstack.org/cgit/openstack/diskimage-builder/tree/diskimage_builder/elements/package-installs/README.rst#n53 | 23:51 |
greghaynes | ah. I think the two pip-and-virtualenv elemetns would use that, then as a user if you wanted pip/virtualenv youd be using element-deps to specify pip-and-virtualenv{2,3,} | 23:52 |
ianw | there's a bit of ordering to worry about ... if we get-pip.py install pip, and it takes over /usr/bin/pip as pip3 things go haywire | 23:54 |
greghaynes | yep, wed have to be explicit about the order the install scripts run in, but thats doable I think... maybe with a big warning comment of 'make sure this runs before the other install pip script' | 23:55 |
greghaynes | it also could get messy if someone wanted to conditionally depend on one or the other since theres no mechanism to do anything dynamic in element-deps | 23:56 |
greghaynes | but thats not any worse than it is ATM | 23:56 |
ianw | and i'm not sure element-deps is ordering dependent. it is "this will happen before me" ... but not stronger than that i don't think | 23:59 |
greghaynes | element-deps arent but the scripts inside the elements are | 23:59 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!