Summary: | Default value for PYTHON_TARGETS (was: python-distutils-ng unfriendly to (new) users (was: app-admin/eclean-kernel-0.3 requires PYTHON_TARGETS="python2_6 python2_7")) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Derk W te Bokkel <derk.tebokkel> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dev-portage, hasufell, jer, leho, mgorny, poncho, rei4dan, skrattaren |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Derk W te Bokkel
2012-05-12 13:42:20 UTC
if eclean-kernel-0.3 is installed it still requires PYTHON_TARGETS to be set properly ... else it blocks any emerges if you had an earlier version installed then the update blocks the emerges until Python_targets is set.. How would one set the environment just for this package in /etc/portage/package.env ? okay created in /etc/portage/env/eclean-kernel containing the line: PYTHON_TARGETS="python2_7 python3_2" created in /etc/portage/package.env/eclean-kernel containing the line: app-admin/eclean-kernel eclean-kernel and all is well .. jer@wieneke /newaches/gentoo/cvs/gentoo-x86/app-admin/eclean-kernel $ ebuild eclean-kernel-0.3.ebuild install Appending /newaches/gentoo/cvs/gentoo-x86 to PORTDIR_OVERLAY... The following REQUIRED_USE flag constraints are unsatisfied: || ( python_targets_python2_6 python_targets_python2_7 ) This is a regular USE_EXPAND to be set in make.conf. I am not the person who can do it for you. @Python, @portage: can we make this switch a little more friendly to users? This is going to get tricky when new/unstable versions of python come out. The package.stable proposal is supposed to help for similar issues: http://archives.gentoo.org/gentoo-pms/msg_0aa9148d070b54ba913debd9279b7351.xml However, it seems like we'd also need a use.stable file in order to tweak default USE settings for the stable users. What was wrong with using eselect python to get/set this information as other packages do? Per discussion on ml: just do it. (In reply to comment #6) > What was wrong with using eselect python to get/set this information as > other packages do? There is no way to call eselect python from make.conf or a profile. The use flags need to be set before the ebuild/eclass code is invoked. (In reply to comment #7) > Per discussion on ml: just do it. I will make the change in the base profile tomorrow. (In reply to comment #8) > (In reply to comment #6) > > What was wrong with using eselect python to get/set this information as > > other packages do? > > There is no way to call eselect python from make.conf or a profile. The use > flags need to be set before the ebuild/eclass code is invoked. But surely there is a way for eselect to set PYTHON_TARGETS. (In reply to comment #10) That's a nice thought, but not a very simple thing to implement. There are a couple of ways I can think of: 1. Modify portage configuration (/etc/make.conf). 2. Set PYTHON_TARGETS in an env.d file, which would override the portage config. I don't really like the idea of modifying make.conf from an eselect module. I'm also not sure how we could allow the user to override eselect python for cases where more than one version of python-2 and python-3 are desired. (In reply to comment #11) How about letting eselect python to write env.d file with PYTHON_TARGETS, which then could be owerriden by user in make.conf and there they could put as many targets as they wish (or combine env.d setting with make.conf). Zac would know better if emerge could work with it that way. (In reply to comment #12) > How about letting eselect python to write env.d file with PYTHON_TARGETS, > which then could be owerriden by user in make.conf and there they could put > as many targets as they wish (or combine env.d setting with make.conf). Zac > would know better if emerge could work with it that way. Yeah, that would work because USE_ORDER (see `man make.conf`) includes env.d. It's kind of ugly though, because the variables from env.d are also exported in your shell. That mean you need to make sure to source /etc/profile after any updates, in order to avoid inconsistencies between the env.d settings and your current shell settings, because USE_ORDER also includes env (your exported shell variables). (In reply to comment #12) > (In reply to comment #11) > > How about letting eselect python to write env.d file with PYTHON_TARGETS, > which then could be owerriden by user in make.conf and there they could put > as many targets as they wish (or combine env.d setting with make.conf). Zac > would know better if emerge could work with it that way. I don't think that makes sense - New major Python releases are not that common, so updating your make.conf shouldn't be a big issue. I tried setting PYTHON_ABIS in env.d file about 1 year ago and I recommend to not use env.d files due to unreliable and unintuitive behavior. (In reply to comment #14) > I don't think that makes sense - New major Python releases are not that > common, so updating your make.conf shouldn't be a big issue. It is not a big issue. But it is an inconvenience. Eselect is for selecting between alternatives, so I think that should be used for the sake of consistency. (In reply to comment #16) > (In reply to comment #14) > > I don't think that makes sense - New major Python releases are not that > > common, so updating your make.conf shouldn't be a big issue. > > It is not a big issue. But it is an inconvenience. Eselect is for selecting > between alternatives, so I think that should be used for the sake of > consistency. Consistency? With what? Which other USE_EXPAND has an eselect module that updates /etc/make.conf? (In reply to comment #17) > Consistency? With what? Which other USE_EXPAND has an eselect module that > updates /etc/make.conf? It's just a common user expectation that their eselect configurations should be "respected" by all Gentoo things. An example is bug 283587. (In reply to comment #17) > Consistency? With what? Which other USE_EXPAND has an eselect module that > updates /etc/make.conf? Consisten way for managing alternatives on Gentoo. And the proposition was not to update /etc/make.conf, but set the variable elsewhere using eselect (and allow for override by user). (In reply to comment #19) > (In reply to comment #17) > > Consistency? With what? Which other USE_EXPAND has an eselect module that > > updates /etc/make.conf? > > Consisten way for managing alternatives on Gentoo. And the proposition was > not to update /etc/make.conf, but set the variable elsewhere using eselect > (and allow for override by user). And consistent way of managing USE is make.conf (& profiles). (In reply to comment #19) > (In reply to comment #17) > > Consistency? With what? Which other USE_EXPAND has an eselect module that > > updates /etc/make.conf? > > Consisten way for managing alternatives on Gentoo. Let me repeat: what other USE_EXPAND variable has eselect module? > And the proposition was > not to update /etc/make.conf, but set the variable elsewhere using eselect > (and allow for override by user). /etc/make.conf is used to set USE and USE_EXPAND variables, like Michał noted. Lets end the discussion about eselect for USE_EXPAND and focus on the core of this bug: default value of PYTHON_TARGETS. (In reply to comment #21) > (In reply to comment #19) > > (In reply to comment #17) > > > Consistency? With what? Which other USE_EXPAND has an eselect module that > > > updates /etc/make.conf? > > > > Consisten way for managing alternatives on Gentoo. > > Let me repeat: what other USE_EXPAND variable has eselect module? Frankly, I don't care. As Zac said, I expect to set python versions to use trough eselect and then emerge to respect that. If that can't be done trough USE_EXPAND, then maybe that is the wrong solution for what it tries to do. Are there better solutions? > > > And the proposition was > > not to update /etc/make.conf, but set the variable elsewhere using eselect > > (and allow for override by user). > > /etc/make.conf is used to set USE and USE_EXPAND variables, like Michał > noted. Fair enough. That is, if USE_EXPAND is really unavoidable in this case. IMHO the core of this bug is that new USE_EXPAND has showed up. (In reply to comment #21) > Lets end the discussion about eselect for USE_EXPAND and focus on the core > of this bug: default value of PYTHON_TARGETS. Yeah, modifying the profile is nice and simple, and I still intend to do it. I just wanted to make sure we consider all of the options. (In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #19) > > > (In reply to comment #17) > > > > Consistency? With what? Which other USE_EXPAND has an eselect module that > > > > updates /etc/make.conf? > > > > > > Consisten way for managing alternatives on Gentoo. > > > > Let me repeat: what other USE_EXPAND variable has eselect module? > > Frankly, I don't care. As Zac said, I expect to set python versions to use > trough eselect and then emerge to respect that. The problem lies in the above sentence: *you* expect, it doesn't mean that everyone else does. > If that can't be done trough > USE_EXPAND, then maybe that is the wrong solution for what it tries to do. You can try coming up with generic solution for eselect to play with USE_EXPAND - check ${PORTDIR}/profiles/desc for complete list. Please use separate bug for this. > Are there better solutions? Not that I'm aware of. > > > > > And the proposition was > > > not to update /etc/make.conf, but set the variable elsewhere using eselect > > > (and allow for override by user). > > > > /etc/make.conf is used to set USE and USE_EXPAND variables, like Michał > > noted. > > Fair enough. That is, if USE_EXPAND is really unavoidable in this case. IMHO > the core of this bug is that new USE_EXPAND has showed up. I think that USE_EXPAND is best solution at this point. Just a crazy idea: /etc/make.conf.d/00-python-abi-{2.{6,7,8},3.{1,2}}.conf And use eselect to switch it on/off, as many other eselect's do. eselect makeconf set python-abi-2.6 on/off. It will also has some use for users - like switching particular PORTDIR_OVERLAY's on and off, or managing ricing CFLAGS/debugging/features... Controlling PYTHON_ABIS via eselect == rebuilding half of the world every eselect python version change. Do we really want it to behave that way? But eselect should be user-switchable. Isn't it all just about "make selecting python ABI more clean&simple than by editing some creepy variables"? Use eselect for setting creepy variables and place them info *.conf.d directory - that's a common practice... (In reply to comment #27) > But eselect should be user-switchable. Isn't it all just about "make > selecting python ABI more clean&simple than by editing some creepy > variables"? Use eselect for setting creepy variables and place them info > *.conf.d directory - that's a common practice... *Please open new bug* for this discussion. (and no - it's not that common) (In reply to comment #24) > > > Let me repeat: what other USE_EXPAND variable has eselect module? > > > > Frankly, I don't care. As Zac said, I expect to set python versions to use > > trough eselect and then emerge to respect that. > > The problem lies in the above sentence: *you* expect, it doesn't mean that > everyone else does. And what exactly is wrong with expressing my opinion? I can talk only for myself and so I do. I'm not saying what everyone else expects, but apperantly I'm not the only one with that view on eselect. You think that you can talk for everyone? (In reply to comment #29) > (In reply to comment #24) > > > > Let me repeat: what other USE_EXPAND variable has eselect module? > > > > > > Frankly, I don't care. As Zac said, I expect to set python versions to use > > > trough eselect and then emerge to respect that. > > > > The problem lies in the above sentence: *you* expect, it doesn't mean that > > everyone else does. > > And what exactly is wrong with expressing my opinion? There's nothing with expressing your opinion about eselect, but please do that in separate bug as this bug is about default value for PYTHON_TARGETS. > I can talk only for > myself and so I do. I'm not saying what everyone else expects, but > apperantly I'm not the only one with that view on eselect. You think that > you can talk for everyone? You're confusing eselect with variables that are in make.conf, as you've noticed also a few people think that those two are good as they are. And please don't put words in my mouth -- I've never said that I'm 'everyone'. (In reply to comment #30) > as this bug is about default value for PYTHON_TARGETS. Maybe you should change summary for this bug then? Just to make _that_ clear (it's not)... (In reply to comment #31) > (In reply to comment #30) > > as this bug is about default value for PYTHON_TARGETS. > > Maybe you should change summary for this bug then? Just to make _that_ clear > (it's not)... Done (if it's still not clear from overly long discussion). okay so setting a default value for PYTHON_TARGETS is a good idea .. but the question arises .. how does it track the python versions installed? or does every python build now need to add itself to this variable when installed and remove itself when uninstalled .. at least I hope that is how it will work .. .. Saves the poor newbie from going crazy .. me .. I've been around for a while but the surprise of seeing the initial behaviour caused me to file this bug .. it would not be obvious to the non-initiates .. just baffling and potentially discouraging .. and inconsistent with previous behaviour .. At this point, haven't we (as in Mike G.) already set python2_7 as a default PYTHON_TARGET? So is this discussion just about adding python3 in there, or adding all installed pythons? I agree with some of the commenters that we have a problem in the sense that eselect and PYTHON_TARGETS may not be in agreement, and this creates very weird scenarios. Even if eselect is just the tool to select the default python executable from among the installed pythons and PYTHON_TARGETS decides which pythons are installed by default and what versions of python python packages are installed for, we need to be very clear about communicating that to users (I got bitten by this myself yesterday, on a box where I'd forgotten I'd set USE_PYTHON). (In reply to comment #34) > At this point, haven't we (as in Mike G.) already set python2_7 as a default > PYTHON_TARGET? So is this discussion just about adding python3 in there, or > adding all installed pythons? > I committed PYTHON_TARGETS="python2_7" to the base profile about 10 minutes ago. > I agree with some of the commenters that we have a problem in the sense that > eselect and PYTHON_TARGETS may not be in agreement, and this creates very > weird scenarios. Even if eselect is just the tool to select the default > python executable from among the installed pythons and PYTHON_TARGETS > decides which pythons are installed by default and what versions of python > python packages are installed for, we need to be very clear about > communicating that to users (I got bitten by this myself yesterday, on a box > where I'd forgotten I'd set USE_PYTHON). Perhaps we could just have eselect python suggest that the user should PYTHON_TARGETS themselves, and give them an example for copy/paste into make.conf. Would that be an ok compromise? (In reply to comment #35) > I committed PYTHON_TARGETS="python2_7" to the base profile about 10 minutes > ago. Now fresh system just after installation from stage3 has Python 3.2 and PYTHON_TARGETS="python2_7". Very logical, very consistent. I'd say that new eclass discussion (which is *really* called for) should be moved from bugzilla to gentoo-python ML or (even better) to Gentoo forums and kept in one place. Yeah, moving this discussion to a mailing list is probably a good idea. (In reply to comment #36) > (In reply to comment #35) > > I committed PYTHON_TARGETS="python2_7" to the base profile about 10 minutes > > ago. > > Now fresh system just after installation from stage3 has Python 3.2 and > PYTHON_TARGETS="python2_7". Very logical, very consistent. You're aware that you can set it to anything you want, including PYTHON_TARGETS="python2_7 python3_2 python1018478_14873284", right? > I'd say that new eclass discussion (which is *really* called for) should be > moved from bugzilla to gentoo-python ML or (even better) to Gentoo forums > and kept in one place. "eclass discussion" happened a long time ago, now we're discussing default value for PYTHON_TARGETS. @Mike: I had the impression you would commit PYTHON_TARGETS="python2_7 python3_2", can we update it to include latest py2 and py3? I also like the solution for eselect to *suggest* PYTHON_TARGETS value, not set it (maybe even with a check if suggested value differs from current). (In reply to comment #38) > @Mike: I had the impression you would commit PYTHON_TARGETS="python2_7 > python3_2", can we update it to include latest py2 and py3? this. please. (In reply to comment #38) > @Mike: I had the impression you would commit PYTHON_TARGETS="python2_7 > python3_2", can we update it to include latest py2 and py3? Will do. I need to do this in arch-specific profiles because python:3.2 is not keyword-ed the same on all arches. (In reply to comment #38) > You're aware that you can set it to anything you want, including > PYTHON_TARGETS="python2_7 python3_2 python1018478_14873284", right? Indeed I am. But I still think that providing system with default configuration that *doesn't make sense whatsoever* is a bit strange. > "eclass discussion" happened a long time ago Is it polite way of saying "please shut up, you're too late, new eclass has been set in stone, take it or leave..." oh wait, I can't leave it unless I leave Gentoo as well. If so, I'll be silent. Or is Python herd still inclined to listen to user's feedback? (In reply to comment #40) > Will do. I need to do this in arch-specific profiles because python:3.2 > is not keyword-ed the same on all arches. Got it :) Thank you Mike. (In reply to comment #41) > (In reply to comment #38) > > You're aware that you can set it to anything you want, including > > PYTHON_TARGETS="python2_7 python3_2 python1018478_14873284", right? > Indeed I am. But I still think that providing system with default > configuration that *doesn't make sense whatsoever* is a bit strange. > > > "eclass discussion" happened a long time ago > Is it polite way of saying "please shut up, you're too late, new eclass has > been set in stone, take it or leave..." oh wait, I can't leave it unless I > leave Gentoo as well. If so, I'll be silent. Or is Python herd still > inclined to listen to user's feedback? That was a nice way to say to stop beating a dead horse. Calm down. I have added PYTHON_TARGETS="python3_2" to make.defaults for amd64, hppa, ppc, ppc64 and x86. (In reply to comment #43) > I have added PYTHON_TARGETS="python3_2" to make.defaults for amd64, hppa, > ppc, ppc64 and x86. I have removed it for HPPA again and I have gone ~hppa on all affected 3.1/3.2 ebuilds. I don't agree that messing in profiles is the right solution for an eclass issue. (In reply to comment #44) > (In reply to comment #43) > > I have added PYTHON_TARGETS="python3_2" to make.defaults for amd64, hppa, > > ppc, ppc64 and x86. > > I have removed it for HPPA again and I have gone ~hppa on all affected > 3.1/3.2 ebuilds. I don't agree that messing in profiles is the right > solution for an eclass issue. PYTHON_TARGETS is arch-dependent to some degree (it shouldn't specify unstable Python for given arch for example), so if you removed it from hppa and dropped to ~hppa for 3.x it should be fine. Mike has added the defaults, closing this bug. (In reply to comment #38) > I also like the solution for eselect to *suggest* PYTHON_TARGETS value, not > set it (maybe even with a check if suggested value differs from current). I have filed bug 416145 for an enhancement to eselect-python. |