Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On 29 September 2012 18:20, Markos Chandras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 09/29/2012 09:53 AM, Micha? Górny wrote: >> Hello, >> >> Instead of the floating patches and p-d-ng modifications I sent >> earlier, here are the two complete (so far, well, initial :P) >> eclasses for review. >> >> They are designed as 'mostly' drop-in python-distutils-ng >> replacement. >> > Hi, > > Are you saying that you are going to remove the python-distutils-ng > eclass in favour of the new eclasses? I don't quite understand the > reasons to be honest. The current python.eclass is too horribly complicated, and should go the way of the dodo ASAP; while on the other hand python-distutils-ng is too limited (e.g. for non-distutils multiple-implementation python needing packages) and oddly named. I fully support this attempt to improve the current situation, and as I understand so does most of our python team. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] GCC 4.7 unmasking
I just added gcc-4.7.2 to the tree, and I'd like to unmask it in a couple weeks. I don't see anything I'd consider a blocker on the tracker*, but 95 open bugs is still a lot. If you have a bug blocking the tracker please take a look at it soon. Many of these are trivial and could make good bugsday projects (if we even do bugsdays anymore). * https://bugs.gentoo.org/390247 PS. still looking for a gcc maintainer who isn't me. -- gcc-porting toolchain, wxwidgets we were never more here, expanse getting broader @ gentoo.org but bigger boats been done by less water signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Clarify the "as-is" license?
On Sat, Sep 29, 2012 at 5:21 PM, Ulrich Mueller wrote: >> On Sat, 29 Sep 2012, Chí-Thanh Christopher Nguyễn wrote: >> If we start to measure the software freedom of the code inside the >> package, then maybe LICENSE is the wrong variable to express this. > > I'm aware that we can't distinguish the two cases. Should we have a > "binary-only" license to catch it? The license isn't binary-only. The license is BSD. It just happens that the thing they're licensing is the binary and not the source. Does it really matter? Before we start overloading the LICENSE flag to represent something other than the license we should probably have a problem to actually fix. As far as freedom of code goes, arguably the code is perfectly free - it just isn't open source. You could legally decompile, modify, recompile, and redistribute it and your assembly language sources as much as you like. Rich
Re: [gentoo-dev] Re: Clarify the "as-is" license?
> On Sat, 29 Sep 2012, Chí-Thanh Christopher Nguyễn wrote: > I have one question: The license can be GPL-compatible but the > software itself non-free. So binary-only packages distributed under > e.g. BSD license should remain BSD or not? Yes, if it's BSD licensed then it should have LICENSE="BSD". > If we start to measure the software freedom of the code inside the > package, then maybe LICENSE is the wrong variable to express this. I'm aware that we can't distinguish the two cases. Should we have a "binary-only" license to catch it? Ulrich
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2012 08:39 PM, Michał Górny wrote: > On Sat, 29 Sep 2012 16:37:15 +0200 Dirkjan Ochtman > wrote: > >> On Sat, Sep 29, 2012 at 4:26 PM, hasufell >> wrote: >>> That still does not explain the reasons why this work was >>> initiated. >>> >>> If there is any way to fix the current eclass, that should be >>> preferred. >> >> I tend to agree. Michał, let me first say I value the time you >> have invested to make the eclasses better. However, at this point >> I have a strong feeling that we have more people willing to write >> code to fix things than we have people building consensus on >> what features/policies/mechanisms we need to make it easy to >> write high-quality ebuilds for Python/distutils. I would prefer >> discussions on problems that the current ebuilds have and >> discussions on how to solve them, not at the code level, but that >> the mechanism level. > > The main issue: noone wants to even touch python.eclass or > anything nearby. > > The second issue: python-distutils-ng isn't good enough. It has > too many things hard-wired. I think I have already pointed enough > problems with it. Not that many people cared to respond. > > It's sad that people don't care to respond when you point the > issues out but then complain when you do something to fix them. > Did you CC gentoo-dev? I cannot find the tread. > [example needed] > ?? I meant that not all tree ebuilds use the same python-eclass implementation which IS a problem. Adding another implementation does not really improve that situation. > Please list the features. Preferably, order them by usefulness, > with exact use cases. > As I said, I think the python herd already did a list on this. Btw. could you give exact examples on how to convert widely used python ebuilds with your eclasses? E.g. dev-python/pygobject dev-python/setuptools or dev-libs/boost? How can I convert shebangs consistently and recursively? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQZ16AAAoJEFpvPKfnPDWzzMgH/0dGzePj8eSrZ3OZDzwMYE3B Vx8BiD2Vd+OnGyq2w0infJpN8lDlGu+8yxGwWervZJ7tIxqabhQokI03tBSyLRgt em5R+AgSiR6GSiIRfMNoFYj+5zR8vz4gHtCzrI47O8W6R6e3fRj3JKShY7+T4Djz vBMyD4ZuxLg0CnvJ05rrc41CEvmAY/aWysS5WNoevdx8Jf8exaVtfp6TXGu/q+JV 7py4gFA5wXmb7UCv9Tcw0IxiglVAfEJRzvRh68TComBKWuUw0YhGd/x2VxaLZ0dr ghCt4XBjyi5g4q1rcDedEPowth1Q/9M6VpP6fT5ZTPVIs5r49G9vMcRymppWetM= =5M+2 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On Sat, 29 Sep 2012 21:20:00 +0200 Pacho Ramos wrote: > El sáb, 29-09-2012 a las 20:40 +0200, Michał Górny escribió: > > On Sat, 29 Sep 2012 17:45:07 +0200 > > hasufell wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On 09/29/2012 05:37 PM, Ian Stakenvicius wrote: > > > > > > > > There isn't so much a problem with the current python-distutils-ng > > > > eclass but rather it's to expand it to a more comprehensive > > > > replacement for both distutils and python eclasses. In order to > > > > do that efficiently, most of the core functionality should be moved > > > > so that the new distutils is more like a wrapper to the new > > > > python. > > > > > > > > This could certainly be done by patching the existing eclass, but > > > > mgorny wants to use new eclass names instead of keeping the > > > > current one. Hence the rename. I think that's about it.. > > > > > > > > > > In that case we are missing 95% of the features of python.eclass. > > > > Please list the features. Preferably, order them by usefulness, with > > exact use cases. > > > > Personally, I usually run: > - python_clean_py-compile_files -> Clean py-compile files to disable > byte-compilation allowing us to drop all various ways of doing this that > were living in the tree some time ago. Hmm, what's the problem with compiling them? Do you mean some case when the results of the compilation are different from the way done by the eclass? > - python_convert_shebangs -> but, I guess this is handled in a different > way in your eclass, no? :/ Depends on what you need. To be honest, I haven't added any code for custom script handling yet, just the usual distutils case. A package which does not explicitly support multiple Python implementations is a completely different things, needing more discussion first and which actually may be handled through a separate eclass if most code of python-r1 proves useless for it. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On 09/29/2012 12:45 PM, Michał Górny wrote: > On Sat, 29 Sep 2012 12:00:18 +0200 > Tomáš Chvátal wrote: > >> 2012/9/29 Michał Górny : >>> Hello, >>> >>> Instead of the floating patches and p-d-ng modifications I sent >>> earlier, here are the two complete (so far, well, initial :P) eclasses >>> for review. >>> >>> They are designed as 'mostly' drop-in python-distutils-ng replacement. >>> >> Hi, >> >> the eclasses look pretty, so good job, >> just one question tho, would it be possible to use more >> debug-something calls so the log file would be populated automatically >> with whats going on (same like eg git-2 eclass)? > > Try now :P. > Looks even nicer, great! lu
Re: [gentoo-dev] Clarify the "as-is" license?
Ulrich Mueller schrieb: >> Why not directly use the FSF freedoms: >> The freedom to run the program, for any purpose (freedom 0). >> The freedom to study how the program works, and change it so it does >> your computing as you wish (freedom 1). >> The freedom to redistribute copies so you can help your neighbor >> (freedom 2). >> The freedom to distribute copies of your modified versions to others >> (freedom 3). > >> I think when combined appropriately, they nicely cover most of the >> cases of current "as-is" packages. > > This has been suggested before, but for license groups. The problem > is that the four freedoms are good criteria for Free Software, but > there's no good mapping to the elements of most non-free licenses. > > Try it yourself for a few concrete cases (of non-free licenses in our > tree), and you'll see what I mean. I tried it on two non-free packages that I maintain (bitstream-cyberbit and radeon-ucode) and it works well there: bitstream-cyberbit: 0 but not 1, 2 or 3. radeon-ucode: 0 and 2 but not 1 or 3. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Re: Clarify the "as-is" license?
Ulrich Mueller schrieb: > I've created licenses/HPND [1] now, and added it to the @OSI-APPROVED > group. So packages whose license matches this template can be changed > from as-is to HPND. (And please, _only_ OSD-compliant packages. > We don't want the same mess again, as we have with as-is.) I have one question: The license can be GPL-compatible but the software itself non-free. So binary-only packages distributed under e.g. BSD license should remain BSD or not? If we start to measure the software freedom of the code inside the package, then maybe LICENSE is the wrong variable to express this. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
El sáb, 29-09-2012 a las 20:40 +0200, Michał Górny escribió: > On Sat, 29 Sep 2012 17:45:07 +0200 > hasufell wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 09/29/2012 05:37 PM, Ian Stakenvicius wrote: > > > > > > There isn't so much a problem with the current python-distutils-ng > > > eclass but rather it's to expand it to a more comprehensive > > > replacement for both distutils and python eclasses. In order to > > > do that efficiently, most of the core functionality should be moved > > > so that the new distutils is more like a wrapper to the new > > > python. > > > > > > This could certainly be done by patching the existing eclass, but > > > mgorny wants to use new eclass names instead of keeping the > > > current one. Hence the rename. I think that's about it.. > > > > > > > In that case we are missing 95% of the features of python.eclass. > > Please list the features. Preferably, order them by usefulness, with > exact use cases. > Personally, I usually run: - python_clean_py-compile_files -> Clean py-compile files to disable byte-compilation allowing us to drop all various ways of doing this that were living in the tree some time ago. - python_convert_shebangs -> but, I guess this is handled in a different way in your eclass, no? :/ signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] GLEP-0062: updated version for review
On Sat, 29 Sep 2012 17:13:14 +0100 Ciaran McCreesh wrote: > On Sat, 29 Sep 2012 11:42:19 +0200 > Michał Górny wrote: > > Following the late discussion, I have updated GLEP-62. It no longer is > > designed to be 'backwards compatible' and instead it was suited for > > addition in a new EAPI. > > You've still not addressed the UI side of it in any way. Haven't I? Maybe you should read it more carefully. > You've also still not provided any kind of reference implementation, > and your "reference implementation" section is still written with a > complete lack of awareness of how dependency resolution is actually > done. I'm sorry I haven't got time yet to write a package manager. I promise I will do it as soon as I have time to do so. Thank you for your patience. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP-0062: updated version for review
On Sat, 29 Sep 2012 09:12:38 -0700 Zac Medico wrote: > On 09/29/2012 02:42 AM, Michał Górny wrote: > > Hello, > > > > Following the late discussion, I have updated GLEP-62. It no longer is > > designed to be 'backwards compatible' and instead it was suited for > > addition in a new EAPI. > > > > Thus, IUSE_RUNTIME is now independent of IUSE, and runtime dependencies > > can be expressed in SDEPEND only. > > Thanks, these changes make it much more manageable. Trying to do > something like this retroactively for existing EAPIs is just a mess. > > > There's still a case of REQUIRED_USE. I'm not really convinced to > > create a REQUIRED_RUNTIME_USE especially for it. Also, it may be > > actually better to put all IUSE_RUNTIME flags to IUSE as well -- since > > the package manager will after all be required to concatenate them > > anyway. > > Will runtime flags be able to interact with buildtime flags then? It > seems like it could be useful, so it we should probably allow it. Sure, > people could write some expressions that don't make sense, but that's > already the case with REQUIRED_USE. Yes, that's the intent, e.g. when a particular runtime feature requires another build-time feature. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On Sat, 29 Sep 2012 17:45:07 +0200 hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/29/2012 05:37 PM, Ian Stakenvicius wrote: > > > > There isn't so much a problem with the current python-distutils-ng > > eclass but rather it's to expand it to a more comprehensive > > replacement for both distutils and python eclasses. In order to > > do that efficiently, most of the core functionality should be moved > > so that the new distutils is more like a wrapper to the new > > python. > > > > This could certainly be done by patching the existing eclass, but > > mgorny wants to use new eclass names instead of keeping the > > current one. Hence the rename. I think that's about it.. > > > > In that case we are missing 95% of the features of python.eclass. Please list the features. Preferably, order them by usefulness, with exact use cases. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On Sat, 29 Sep 2012 16:37:15 +0200 Dirkjan Ochtman wrote: > On Sat, Sep 29, 2012 at 4:26 PM, hasufell wrote: > > That still does not explain the reasons why this work was initiated. > > > > If there is any way to fix the current eclass, that should be preferred. > > I tend to agree. Michał, let me first say I value the time you have > invested to make the eclasses better. However, at this point I have a > strong feeling that we have more people willing to write code to fix > things than we have people building consensus on what > features/policies/mechanisms we need to make it easy to write > high-quality ebuilds for Python/distutils. I would prefer discussions > on problems that the current ebuilds have and discussions on how to > solve them, not at the code level, but that the mechanism level. The main issue: noone wants to even touch python.eclass or anything nearby. The second issue: python-distutils-ng isn't good enough. It has too many things hard-wired. I think I have already pointed enough problems with it. Not that many people cared to respond. It's sad that people don't care to respond when you point the issues out but then complain when you do something to fix them. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On Sat, 29 Sep 2012 15:49:32 +0200 hasufell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/29/2012 12:49 PM, Michał Górny wrote: > > On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras > > wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > >> > >> On 09/29/2012 09:53 AM, Micha? Górny wrote: > >>> Hello, > >>> > >>> Instead of the floating patches and p-d-ng modifications I sent > >>> earlier, here are the two complete (so far, well, initial :P) > >>> eclasses for review. > >>> > >>> They are designed as 'mostly' drop-in python-distutils-ng > >>> replacement. > >>> > >> Hi, > >> > >> Are you saying that you are going to remove the > >> python-distutils-ng eclass in favour of the new eclasses? I don't > >> quite understand the reasons to be honest. > > > > The reason is simple -- I can't fix it without changing the API. > > Changing the API on a live eclass is confusing, and considering > > that it is not used by many packages, it's easier to lastrite it. > > > > Also, this fixes the name not to have any '-ng' nor '-ds9'. > > > > What are the reasons to change the API in the first place? There has > to be a good reason, cause this will involve yet another migration of > many ebuilds. I don't see any bugreports. I have pointed out what changes to the API are _necessary_ to introduce a good eclass on gentoo-python@. Otherwise, the eclass would have to have at least two almost identical functions doing the same thing, one universal and one for specific case where specific parameters are passed (and not used in a single ebuild). > I fear this will cause more confusion, i.e. some ebuilds using the old > distutils, some using python-distutils-ng and some using distutils-r1 > resulting in weird tree behavior. [example needed] -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP-0062: updated version for review
On Sat, 29 Sep 2012 11:42:19 +0200 Michał Górny wrote: > Following the late discussion, I have updated GLEP-62. It no longer is > designed to be 'backwards compatible' and instead it was suited for > addition in a new EAPI. You've still not addressed the UI side of it in any way. You've also still not provided any kind of reference implementation, and your "reference implementation" section is still written with a complete lack of awareness of how dependency resolution is actually done. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] GLEP-0062: updated version for review
On 09/29/2012 02:42 AM, Michał Górny wrote: > Hello, > > Following the late discussion, I have updated GLEP-62. It no longer is > designed to be 'backwards compatible' and instead it was suited for > addition in a new EAPI. > > Thus, IUSE_RUNTIME is now independent of IUSE, and runtime dependencies > can be expressed in SDEPEND only. Thanks, these changes make it much more manageable. Trying to do something like this retroactively for existing EAPIs is just a mess. > There's still a case of REQUIRED_USE. I'm not really convinced to > create a REQUIRED_RUNTIME_USE especially for it. Also, it may be > actually better to put all IUSE_RUNTIME flags to IUSE as well -- since > the package manager will after all be required to concatenate them > anyway. Will runtime flags be able to interact with buildtime flags then? It seems like it could be useful, so it we should probably allow it. Sure, people could write some expressions that don't make sense, but that's already the case with REQUIRED_USE. -- Thanks, Zac
[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal
On Tue, 25 Sep 2012 15:46:14 -0700 Brian Harring wrote: > Fun fact; peoples usage of labels in exherbo is thus: > > build+run: > set of deps > run: > set of deps/conditionals/etc That's largely because there are a lot of former Gentoo developers there who all said "oh, yeah, I forgot we could do it the other way" when this was pointed out... > > Specification in terms of rendering has a huge problem, though. > > Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what > > does this do? > > > > || ( dep:build? ( a ) dep:run? ( b ) ) > > Honestly, I was waiting for you to bring this up :) > > You're conflating two different things here; > 1) someone being a dumb ass and writing what's effectively a || ( > atom) block, just doing so in a manner w/out any reason to do so. > > 2) Your ongoing jihad against || (), specifically the occasionally > valid complaint that build/rdepend different means the resolver can > get stuck in certain pathways when slots are involved, abi, etc. > > Either way, in my proposal, I'm not going to single that out and try > blocking it. The rendered version of it is still stable, albeit if > it's build/run it's unlikely to be desired if there is ABI involved > (for non ABI, specifically self-bootstrapping codebases, I suspect > someone could come up with a valid construct- sed has something > similar if memory serves). The rendered version ends up as ( a b ), in effect... It doesn't end up as || ( a (at build time) b (at runtime) ). > Which is stupid, but syntactically correct. Nor is this a new issue, > thus I don't particularly agree with your approach of trying to sink > the proposal via an orthogonal problem. No, you're introducing a new kind of weirdness for || ( ) here. > Either way, via > http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt > > , I think it's pretty clear labels in real world usage aren't > bringing anything to the tabel that we wouldn't have via my proposal; > that leaves labels as just a different syntax (perhaps aesthetically > more pleasing at first glance, but the label stacking bit via exheres > analysis is proven to be something people explicitly go out of their > way to protect against; meaning the aesthetics have a mental > model cost). It's not "go out of their way to protect against". It's "there's an easy way of making sure everything is composable". Your misappropriation of use flags doesn't have that. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] patch eutils.eclass for EAPI 5
On Thu, 27 Sep 2012 10:23:50 -0700
Zac Medico wrote:
> Something like this would work with current versions of portage:
>
> if ! declare -F usex >/dev/null ; then
> usex() { use "$1" && echo "${2-yes}$4" || echo "${3-no}$5" ; }
> fi
>
> However, it's probably not a good idea to assume that the package
> manager defines usex prior to sourcing the eclass.
It's also not a good idea to assume that usex is a function.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 29 Sep 2012 17:45:07 +0200 hasufell wrote: > In that case we are missing 95% of the features of python.eclass. You say that like it's a bad thing... Seriously, most of the problem with python.eclass (and several other problematic eclasses) is that it tries to do far too much all in one place. More smaller eclasses is a good thing. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlBnGacACgkQ96zL6DUtXhFFCgCfXr4BzUaN7L/WaAtYV//JOkjW ES4AoNQU0/PwOBdzBTgspOt45V/2FDxG =fvDp -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2012 05:50 PM, Ian Stakenvicius wrote: > On 29/09/12 11:45 AM, hasufell wrote: >> On 09/29/2012 05:37 PM, Ian Stakenvicius wrote: > >>> There isn't so much a problem with the current >>> python-distutils-ng eclass but rather it's to expand it to a >>> more comprehensive replacement for both distutils and python >>> eclasses. In order to do that efficiently, most of the core >>> functionality should be moved so that the new distutils is more >>> like a wrapper to the new python. > >>> This could certainly be done by patching the existing eclass, >>> but mgorny wants to use new eclass names instead of keeping the >>> current one. Hence the rename. I think that's about it.. > > >> In that case we are missing 95% of the features of >> python.eclass. > > > Aha, but do we really -need- 95% of the features? Yeah, maybe not. But that should be discussed beforehand imo. So that we really design this eclass together. Otherwise I fear we will end up getting a 4th implementation... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQZxmzAAoJEFpvPKfnPDWzi2AIAKQjjlbuf8K3TUFGmXPldTi4 sQJhwZjo4sngQF1zql4K2RJHnx2R6qsr/YteZ/4ek2yTg356oqkMjAyk5BV5Dpv8 shJugkgvAd3iZWVOUqQEMjxl+Rd3wRmgAw5oC+EEXrck6vOOgQbla/RdLwYFstkP 5Pmp+0hnksRcAnGhOiw7W0JLBJzuhPjoeUGdXVVVwuaPIzlgis0Jv8fSMeP4jxpT vM5EOuvrwpM+gJzkpH0ABCdVHMyigufXCKED11JOrRTUA1fgT2XoWBMCblBoMXtH e6WzUT5NojLlHn4E3psqy3kA4bqzRdMm6u3Iw4bPLFnl0vUaCGYqVfvL1OYkTU4= =gbNx -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/09/12 11:45 AM, hasufell wrote: > On 09/29/2012 05:37 PM, Ian Stakenvicius wrote: > >> There isn't so much a problem with the current >> python-distutils-ng eclass but rather it's to expand it to a more >> comprehensive replacement for both distutils and python eclasses. >> In order to do that efficiently, most of the core functionality >> should be moved so that the new distutils is more like a wrapper >> to the new python. > >> This could certainly be done by patching the existing eclass, but >> mgorny wants to use new eclass names instead of keeping the >> current one. Hence the rename. I think that's about it.. > > > In that case we are missing 95% of the features of python.eclass. > Aha, but do we really -need- 95% of the features? :) Personally (this is my investment in this project) I'd just like to see non-distutils ebuilds needing python support using PYTHON_TARGETS. Also, I'd like to see that anything at all which new-distutils (whatever it be called) might need the old python.eclass for be integrated into new-distutils (probably via new-python). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBnGKkACgkQ2ugaI38ACPCUGQD/f2tf7bjyxkq52In7OrH+nDSL nWLUWc9btwRm3Uuyd3AA/3tFI8uOiqpAVS7Ze4ScCt1UHi7LdvXgYGZRxPbJUbvS =4o7s -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2012 05:37 PM, Ian Stakenvicius wrote: > > There isn't so much a problem with the current python-distutils-ng > eclass but rather it's to expand it to a more comprehensive > replacement for both distutils and python eclasses. In order to > do that efficiently, most of the core functionality should be moved > so that the new distutils is more like a wrapper to the new > python. > > This could certainly be done by patching the existing eclass, but > mgorny wants to use new eclass names instead of keeping the > current one. Hence the rename. I think that's about it.. > To be a bit more precise: if we really want to replace python.eclass we should start the new eclass by gathering a list of features the python herd and developers want. I think there already is something like that, no? I don't see a point in adding a draft-eclass to the tree. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQZxguAAoJEFpvPKfnPDWz29QH/2mylpPs2759z27RKqvmdGh8 X8bV+CMRqWBPl1+blXpGlX9Bf6Er7MRQD1XarqpgvT+1ALhJYL0SZO/MA5DTxvkJ 1EdhdlIVK2ew6UTOmH0jin+wSuspBE1ZpLJCLLWQ94PQgLScaVmAj+XWMLuCbSOF GfKW1thACamIKl3ej1foxMzD9mtSvufqI+eZQd0V341jHR1v5JF8LeqfC3C8c8nR AalRvqbh1QltzcX7ao8wWeq4cYUAGrYACrjQqiEtEnMuUkk2upQMzdjt0I41D5vT oOJtlsk742SLdE4ZIHCsXbjeEOKaFiLBlDjHvcvkWl4MkbKQ6pGpnsTYSpDm8+k= =iY6x -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2012 05:37 PM, Ian Stakenvicius wrote: > > There isn't so much a problem with the current python-distutils-ng > eclass but rather it's to expand it to a more comprehensive > replacement for both distutils and python eclasses. In order to > do that efficiently, most of the core functionality should be moved > so that the new distutils is more like a wrapper to the new > python. > > This could certainly be done by patching the existing eclass, but > mgorny wants to use new eclass names instead of keeping the > current one. Hence the rename. I think that's about it.. > In that case we are missing 95% of the features of python.eclass. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQZxeDAAoJEFpvPKfnPDWzmRAH+wThUWb1jzE+jFUbTeuByKca a4wVAFWy8ruGIQI82+/9bY5zZqitiqU1MijAixbdgwLwGeFurD6UBx+7vAUJ01YR G5ALZOqxK7js0TJ3pv9wXiNihhoGjXGby+8MtbUogJ5mqB9r9vYaZaOUMRpaOpkg VOgpVXX2YGixuder8JRo2snVQkd+hpMoZ3EI4w0EaSofhNGEV8f1BP27OUNgts1K iH3EuVU3CF5STqGK4Fo7wwNwhsbzkQbMBVe/V9zBvJQEZyUVU9EuQ0+bvnedzAMB PPgEXmNdxxbALxIR3xSpi7o/dyl21feJK968C9ObPpwMMloaNfQewQYB0MNPrY4= =CEMA -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/09/12 10:26 AM, hasufell wrote: > On 09/29/2012 04:19 PM, Ian Stakenvicius wrote: >> On 29/09/12 09:49 AM, hasufell wrote: >>> On 09/29/2012 12:49 PM, Michał Górny wrote: On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras wrote: > > -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > > On 09/29/2012 09:53 AM, Micha? Górny wrote: >> Hello, >> >> Instead of the floating patches and p-d-ng modifications >> I sent earlier, here are the two complete (so far, well, >> initial :P) eclasses for review. >> >> They are designed as 'mostly' drop-in python-distutils-ng >> replacement. >> > Hi, > > Are you saying that you are going to remove the > python-distutils-ng eclass in favour of the new eclasses? I > don't quite understand the reasons to be honest. > The reason is simple -- I can't fix it without changing the API. Changing the API on a live eclass is confusing, and considering that it is not used by many packages, it's easier to lastrite it. > Also, this fixes the name not to have any '-ng' nor '-ds9'. > > >>> What are the reasons to change the API in the first place? >>> There has to be a good reason, cause this will involve yet >>> another migration of many ebuilds. I don't see any bugreports. > >>> I fear this will cause more confusion, i.e. some ebuilds using >>> the old distutils, some using python-distutils-ng and some >>> using distutils-r1 resulting in weird tree behavior. > > >> Given that at present, distutils-r1 and python-distutils-ng have >> identical end-results, I think that the introduction of >> distutils-r1 to the tree should also involve a sed against all >> the existing ebuilds using python-distutils-ng to move them to >> the new eclass. Then python-distutils-ng only needs to remain to >> support overlays. > > > > That still does not explain the reasons why this work was > initiated. > > If there is any way to fix the current eclass, that should be > preferred. > There isn't so much a problem with the current python-distutils-ng eclass but rather it's to expand it to a more comprehensive replacement for both distutils and python eclasses. In order to do that efficiently, most of the core functionality should be moved so that the new distutils is more like a wrapper to the new python. This could certainly be done by patching the existing eclass, but mgorny wants to use new eclass names instead of keeping the current one. Hence the rename. I think that's about it.. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBnFbcACgkQ2ugaI38ACPAirwD/SqHvaJfc73pYzxSoow0ORPJY mSe1aS9kNk7SGT4ey1EA/jLPc1+of8Rwh3BFxeGfk0H1Go4mr/AbqhLDPnkxO2Sn =QUTg -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On Sat, Sep 29, 2012 at 4:26 PM, hasufell wrote: > That still does not explain the reasons why this work was initiated. > > If there is any way to fix the current eclass, that should be preferred. I tend to agree. Michał, let me first say I value the time you have invested to make the eclasses better. However, at this point I have a strong feeling that we have more people willing to write code to fix things than we have people building consensus on what features/policies/mechanisms we need to make it easy to write high-quality ebuilds for Python/distutils. I would prefer discussions on problems that the current ebuilds have and discussions on how to solve them, not at the code level, but that the mechanism level. Cheers, Dirkjan
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2012 04:19 PM, Ian Stakenvicius wrote: > On 29/09/12 09:49 AM, hasufell wrote: >> On 09/29/2012 12:49 PM, Michał Górny wrote: >>> On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras >>> wrote: > -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/29/2012 09:53 AM, Micha? Górny wrote: > Hello, > > Instead of the floating patches and p-d-ng modifications I > sent earlier, here are the two complete (so far, well, > initial :P) eclasses for review. > > They are designed as 'mostly' drop-in python-distutils-ng > replacement. > Hi, Are you saying that you are going to remove the python-distutils-ng eclass in favour of the new eclasses? I don't quite understand the reasons to be honest. > >>> The reason is simple -- I can't fix it without changing the >>> API. Changing the API on a live eclass is confusing, and >>> considering that it is not used by many packages, it's easier >>> to lastrite it. > >>> Also, this fixes the name not to have any '-ng' nor '-ds9'. > > >> What are the reasons to change the API in the first place? There >> has to be a good reason, cause this will involve yet another >> migration of many ebuilds. I don't see any bugreports. > >> I fear this will cause more confusion, i.e. some ebuilds using >> the old distutils, some using python-distutils-ng and some using >> distutils-r1 resulting in weird tree behavior. > > > Given that at present, distutils-r1 and python-distutils-ng have > identical end-results, I think that the introduction of > distutils-r1 to the tree should also involve a sed against all the > existing ebuilds using python-distutils-ng to move them to the new > eclass. Then python-distutils-ng only needs to remain to support > overlays. > > That still does not explain the reasons why this work was initiated. If there is any way to fix the current eclass, that should be preferred. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQZwUtAAoJEFpvPKfnPDWz+g4IAIL0eFfX6rMHKBxtNkCGt7yo dnPMiAjlbRwDVkpCBnorATwLpnHhsRfsHtHXkQrNXWzgGvSgOETpvGzmFgvPzr4L lvOs3ND8BFZz3OiQuw3K2GrwInbQCXg1oFlKdBuLOom7WxtePVXeJsK3Ck4coGcH NIfYlQNLaISp0CvUhGg3yF6/PjSCZ9vwfIN7muY1OVspE0DWXCRIZoOs623RixTS cwzFRIdlxeJgw+JEuLN8wSsXe+Ir3bmmFOiRF+FD6LzjoYdh0xRyGX6Qgg974F7f yb2aOT2MCMANWrMgdYiNuRZGJNvUagZ78PRIGHWNw+PzDaNC3jXqrTBsGpkk2Fc= =azK1 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 29/09/12 09:49 AM, hasufell wrote: > On 09/29/2012 12:49 PM, Michał Górny wrote: >> On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras >> wrote: > >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >>> >>> On 09/29/2012 09:53 AM, Micha? Górny wrote: Hello, Instead of the floating patches and p-d-ng modifications I sent earlier, here are the two complete (so far, well, initial :P) eclasses for review. They are designed as 'mostly' drop-in python-distutils-ng replacement. >>> Hi, >>> >>> Are you saying that you are going to remove the >>> python-distutils-ng eclass in favour of the new eclasses? I >>> don't quite understand the reasons to be honest. > >> The reason is simple -- I can't fix it without changing the API. >> Changing the API on a live eclass is confusing, and considering >> that it is not used by many packages, it's easier to lastrite >> it. > >> Also, this fixes the name not to have any '-ng' nor '-ds9'. > > > What are the reasons to change the API in the first place? There > has to be a good reason, cause this will involve yet another > migration of many ebuilds. I don't see any bugreports. > > I fear this will cause more confusion, i.e. some ebuilds using the > old distutils, some using python-distutils-ng and some using > distutils-r1 resulting in weird tree behavior. > Given that at present, distutils-r1 and python-distutils-ng have identical end-results, I think that the introduction of distutils-r1 to the tree should also involve a sed against all the existing ebuilds using python-distutils-ng to move them to the new eclass. Then python-distutils-ng only needs to remain to support overlays. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBnA1YACgkQ2ugaI38ACPBtCgD/UXW804+tsTOnI0RtfWfhiewK a0W9DXplPRprWYZg4mQBAIWbRf+AJDrIqGvELiwt3p0FXChbCYypHDmm3tb8ljxL =isBB -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/29/2012 12:49 PM, Michał Górny wrote: > On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras > wrote: > >> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >> >> On 09/29/2012 09:53 AM, Micha? Górny wrote: >>> Hello, >>> >>> Instead of the floating patches and p-d-ng modifications I sent >>> earlier, here are the two complete (so far, well, initial :P) >>> eclasses for review. >>> >>> They are designed as 'mostly' drop-in python-distutils-ng >>> replacement. >>> >> Hi, >> >> Are you saying that you are going to remove the >> python-distutils-ng eclass in favour of the new eclasses? I don't >> quite understand the reasons to be honest. > > The reason is simple -- I can't fix it without changing the API. > Changing the API on a live eclass is confusing, and considering > that it is not used by many packages, it's easier to lastrite it. > > Also, this fixes the name not to have any '-ng' nor '-ds9'. > What are the reasons to change the API in the first place? There has to be a good reason, cause this will involve yet another migration of many ebuilds. I don't see any bugreports. I fear this will cause more confusion, i.e. some ebuilds using the old distutils, some using python-distutils-ng and some using distutils-r1 resulting in weird tree behavior. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQZvxsAAoJEFpvPKfnPDWzL1IH/iaChrfPET4KArZzaViXJjlL 4pM2tmgByJNAgtFjwLwz3c6lqdJGAV8Uf4VpPTec+Z7lj0v0SDj04YI63CgFZ2N/ R7edGAoJdGOFDv/oOY+bP38PeWpnuguOvEaKI8EEqaJgLne29wPEQ7+KcWe8M6hM tA41lIIFpK2PN+kIHdItbSl8aRZmm9NorfUCukFfs1odwV+C0B3rP4mJZQW+TnbR DmDqFCFQF/r1k+n17wARqvcCL+hBqs/CvTG7K8Z/mNWD/Dove1vMB1ir8p8KnYSO TULgpcVEK4VuXjHrccLhmO4ODWZiXn/yWKws3z+XmRwIwBB7m9IhC8G32aeyqoE= =gU6H -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On Sat, 29 Sep 2012 11:20:31 +0100 Markos Chandras wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 09/29/2012 09:53 AM, Micha? Górny wrote: > > Hello, > > > > Instead of the floating patches and p-d-ng modifications I sent > > earlier, here are the two complete (so far, well, initial :P) > > eclasses for review. > > > > They are designed as 'mostly' drop-in python-distutils-ng > > replacement. > > > Hi, > > Are you saying that you are going to remove the python-distutils-ng > eclass in favour of the new eclasses? I don't quite understand the > reasons to be honest. The reason is simple -- I can't fix it without changing the API. Changing the API on a live eclass is confusing, and considering that it is not used by many packages, it's easier to lastrite it. Also, this fixes the name not to have any '-ng' nor '-ds9'. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On Sat, 29 Sep 2012 12:00:18 +0200
Tomáš Chvátal wrote:
> 2012/9/29 Michał Górny :
> > Hello,
> >
> > Instead of the floating patches and p-d-ng modifications I sent
> > earlier, here are the two complete (so far, well, initial :P) eclasses
> > for review.
> >
> > They are designed as 'mostly' drop-in python-distutils-ng replacement.
> >
> Hi,
>
> the eclasses look pretty, so good job,
> just one question tho, would it be possible to use more
> debug-something calls so the log file would be populated automatically
> with whats going on (same like eg git-2 eclass)?
Try now :P.
--
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: python-r1
# @MAINTAINER:
# Python herd
# @AUTHOR:
# Author: MichaŠGórny
# Based on work of: Krzysztof Pawlik
# @BLURB: A common, simple eclass for Python packages.
# @DESCRIPTION:
# A common eclass providing helper functions to build and install
# packages supporting being installed for multiple Python
# implementations.
#
# This eclass sets correct IUSE and REQUIRED_USE. It exports PYTHON_DEPS
# and PYTHON_USEDEP so you can create correct dependencies for your
# package easily. It also provides methods to easily run a command for
# each enabled Python implementation and duplicate the sources for them.
case "${EAPI}" in
0|1|2|3)
die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
;;
4)
# EAPI=4 needed for REQUIRED_USE
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac
# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
# @INTERNAL
# @DESCRIPTION:
# All supported Python implementations, most preferred last.
_PYTHON_ALL_IMPLS=(
jython2_5
pypy1_8 pypy1_9
python3_1 python3_2
python2_5 python2_6 python2_7
)
# @ECLASS-VARIABLE: PYTHON_COMPAT
# @DESCRIPTION:
# This variable contains a space separated list of Python
# implementations a package supports. It must be set before
# the `inherit' call. The default is to enable all implementations.
#
# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar,
# the eclass will implicitly convert it to an array.
: ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
# @ECLASS-VARIABLE: PYTHON_REQ_USE
# @DEFAULT_UNSET
# @DESCRIPTION:
# The list of USEflags required to be enabled on the chosen Python
# implementations, formed as a USE-dependency string. It should be valid
# for all implementations in PYTHON_COMPAT, so it may be necessary to
# use USE defaults.
#
# Example:
# @CODE
# PYTHON_REQ_USE="gdbm,ncurses(-)?"
# @CODE
#
# Will cause the Python dependencies to look like:
# @CODE
# python_targets_pythonX_Y? (
# dev-lang/python:X_Y[gdbm,ncurses(-)?] )
# @CODE
# @ECLASS-VARIABLE: PYTHON_DEPS
# @DESCRIPTION:
# This is an eclass-generated Python dependency string for all
# implementations listed in PYTHON_COMPAT. It should be used
# in RDEPEND and/or DEPEND like:
#
# @CODE
# RDEPEND="${PYTHON_DEPS}
# dev-foo/mydep"
# DEPEND="${RDEPEND}"
# @CODE
# @ECLASS-VARIABLE: PYTHON_USEDEP
# @DESCRIPTION:
# This is an eclass-generated USE-dependency string which can be used to
# depend on another Python package being built for the same Python
# implementations. It should be used like:
#
# @CODE
# RDEPEND="dev-python/foo[${PYTHON_USEDEP}]"
# @CODE
PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )
_python_set_globals() {
local flags=( "${PYTHON_COMPAT[@]/#/python_targets_}" )
local optflags=${flags[@]/%/?}
IUSE=${flags[*]}
REQUIRED_USE="|| ( ${flags[*]} )"
PYTHON_USEDEP=${optflags// /,}
PYTHON_DEPS=
local i
for i in ${PYTHON_COMPAT[@]}; do
local d
case ${i} in
python*)
d='dev-lang/python';;
jython*)
d='dev-java/jython';;
pypy*)
d='dev-python/pypy';;
*)
die "Invalid implementation: ${i}"
esac
local v=${i##*[a-z]}
local usestr
[[ ${PYTHON_REQ_USE} ]] && usestr="[${PYTHON_REQ_USE}]"
PYTHON_DEPS+=" python_targets_${i}? (
${d}:${v/_/.}${usestr} )"
done
}
_python_set_globals
# @FUNCTION: python_get_PYTHON
# @USAGE:
# @DESCRIPTION:
# Get the Python executable name for the given implementation. Please
# note that this this function returns the 'basename' only.
# If using it for a hashbang, please use #!/usr/bin/env.
python_get_PYTHON() {
debug-print-function ${FUNCNAME} "${@}"
local impl=${1/_/.}
local ret
case "${impl}" in
python*|jython*)
ret=${impl}
;;
p
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
On Sat, 29 Sep 2012 12:00:18 +0200 Tomáš Chvátal wrote: > 2012/9/29 Michał Górny : > > Hello, > > > > Instead of the floating patches and p-d-ng modifications I sent > > earlier, here are the two complete (so far, well, initial :P) eclasses > > for review. > > > > They are designed as 'mostly' drop-in python-distutils-ng replacement. > > > Hi, > > the eclasses look pretty, so good job, > just one question tho, would it be possible to use more > debug-something calls so the log file would be populated automatically > with whats going on (same like eg git-2 eclass)? Can do. Was just lazy ;P. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 09/29/2012 09:53 AM, Micha? Górny wrote: > Hello, > > Instead of the floating patches and p-d-ng modifications I sent > earlier, here are the two complete (so far, well, initial :P) > eclasses for review. > > They are designed as 'mostly' drop-in python-distutils-ng > replacement. > Hi, Are you saying that you are going to remove the python-distutils-ng eclass in favour of the new eclasses? I don't quite understand the reasons to be honest. - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJQZstvAAoJEPqDWhW0r/LCC4gQAJmmseSriDS8ahCnkUNBm+61 NGxGijft0zE8qFvdLDH+koQ+ym8/KrMvZcp5U1pLEGDOBVXYj33nOQ9kA24rKBvz Ro2Ydvxcj0Zo/nXGmLB0Mr9IaW4oWY8A16iY24qCpmPV1AWJXdoB0gdtXcDS4MmD +LT19sRMqJstjUXbS02xrWS8lrbcPxVqVkfAPtFo82+/rtceHu+ymSVgJwkTQgBV tKLdI16hK3x9pvceMgaYlC1W32yWq3YUOn3mvFjh4EjANrZ64ED1Q3A+QCYe pUSwx3BGTZnQK6WQtSer/8O/oW7FoR5DooJTNsg1xrPTEdPd79D28TThy3ollACP F5GtKyZO5gFK4SxQdbYfo9Su1Wa0XYybLHihnJDUVHuF2/AchSFW4CtGHfxQ4A0g HWtEgdfRzk5kTUwR2LUhrisei3c6qpB0KGcZZCpi5FF9s150Si2wlKi2PbffAfil 0vLML3mnZnez5bWzPB1DqHf5eWdM00/BFaG4IQJkipwC3jJQ/rye9ruAv2UTM/Rs UH6FQCfTRbScaf0E2WCGMIr33//HsIzy7KPAMAyfJWmxsBGwYHtouci7rQgUZIxn +MdLQuzTYkUgybdnkhLmEeThl8coNwVeEzXwoQZGlciszz6cniSu66WbEEAUxgTP 5F9+vTb5XF1Jq+ZXrrb8 =7EZ5 -END PGP SIGNATURE-
Re: [gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
2012/9/29 Michał Górny : > Hello, > > Instead of the floating patches and p-d-ng modifications I sent > earlier, here are the two complete (so far, well, initial :P) eclasses > for review. > > They are designed as 'mostly' drop-in python-distutils-ng replacement. > Hi, the eclasses look pretty, so good job, just one question tho, would it be possible to use more debug-something calls so the log file would be populated automatically with whats going on (same like eg git-2 eclass)? Cheers Tom
Re: [gentoo-dev] Addressing GLEP-62 itself
On Wed, 26 Sep 2012 03:29:17 -0700 Brian Harring wrote: > On Wed, Sep 26, 2012 at 08:02:44AM +0200, Micha?? G??rny wrote: > > On Tue, 25 Sep 2012 12:54:39 -0700 > > Brian Harring wrote: > > > > > On Tue, Sep 25, 2012 at 08:58:07PM +0200, Micha?? G??rny wrote: > > > > On Tue, 25 Sep 2012 14:47:33 -0400 > > > > Ian Stakenvicius wrote: > > > > > > > > > Based on the above I do expect the reference implementation would also > > > > > need to change. I expect, for instance, that the PM's > > > > > metadata-handling would need to occur as normal even though none of > > > > > the package's phase functions would run, that is, *DEPEND > > > > > (realistically RDEPEND as that should be the only one affected here, > > > > > maybe PDEPEND too) and USE/PKGUSE would get updated. Since portage > > > > > would not be re-emerging the package from the tree the original ebuild > > > > > would remain. > > > > > > > > Yes, unless I'm missing something that's the intent. I will re-read > > > > and update the GLEP a bit sometime this week. > > > > > > There's a fairly strong user interaction component here, along w/ > > > potential nastyness for ebuilds (the proposal assume that a flag will > > > be toggable in all cases within an ebuild if IUSE_RUNTIME specified; I > > > guarantee instances where that fails can be found in the tree if a > > > basic audit was done). Additionally, this *is* useless if it's done > > > in a form the UI an't display/handle; Ciaran may bitch about > > > REQUIRED_USE's UI (which I knew going in was going to be > > > problematic, just to be clear), but he's right on that front. > > ^^^ This point still needs addressing. What kind of addressing? The user interaction works like usual -- portage lists a bunch of flags, some of them may have additional hammers or sickles to mean that they will not trigger the rebuild. Nothing more is required. What is even more important, there is nothing new to learn for the user. In fact, he doesn't need anything new from UI. He will just set the flag like he did 10 years ago. > > > Additionally, this needs to be thought out how it'll interact with > > > eclasses; what stacking, etc. It doesn't cover the basics there to > > > say the least. > > > > The proposal didn't cover eclasses at all. Is there a need to do so or > > are we chasing some kind of perfection based on filling all unused > > slots? > > Eclass stacking here matters; if it's stacked, it means ebuilds have > to use out of bound (ie, other vars) to tell the eclass when it > shouldn't mark a flag as runtime toggable. If it's not stacked by > the pm, then they have to manually stack; that differs from the norm > and makes it easier to screwup; however; does allow for them to > filter, albeit a slight pain in the ass doing so. > > There's a choice there, and the answer matters, so yes, you should > actually have a complete glep before trying to shove it up to the > council and extract a vote out of them. Lest the intention is to just > have them kick it back to the curb... As others have said, we're not stacking it. Using it in eclasses is whacky and should be avoided. End of the story. > > > Pretty much, this needs an implementation, partial conversion of the > > > tree to demonstrate it. > > > > > > Just to prove that fricking point; if you had tried implementing this, > > > a full investigation of what's involved alone, you'd have spotted that > > > the core of the proposal is based on a wrong assumption. > > > > > > Portage doesn't write unfinalized DEPEND/RDEPEND/PDEPEND to the VDB. > > > > There's a footnote there, saying: > > > > The package manager has to ensure that all relevant information is > > stored in the installed package metadata. > > Frankly I don't fully buy that you were aware of this issue from the > start of the proposal; the wording partially covers it however. > Ddoesn't call it out, but via tha req it dumps it on the package > manager developers heads to sort it- which already is the case. > Binpkgs minimally weren't addressed which is why I still don't think > this was actually spotted up front. We talked about it, don't you remember? That's why I have updated the spec and put the whole implementation details thing with special note what needs to be stored in metadata. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] GLEP-0062: updated version for review
Hello, Following the late discussion, I have updated GLEP-62. It no longer is designed to be 'backwards compatible' and instead it was suited for addition in a new EAPI. Thus, IUSE_RUNTIME is now independent of IUSE, and runtime dependencies can be expressed in SDEPEND only. There's still a case of REQUIRED_USE. I'm not really convinced to create a REQUIRED_RUNTIME_USE especially for it. Also, it may be actually better to put all IUSE_RUNTIME flags to IUSE as well -- since the package manager will after all be required to concatenate them anyway. -- Best regards, Michał Górny GLEP: 62 Title: Optional runtime dependencies via runtime-switchable USE flags Version: $Revision: 1.2 $ Last-Modified: $Date: 2012/07/11 20:24:37 $ Author: MichaÅ Górny Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 17 Jun 2012 Post-History: 11 Jul 2012, 29 Sep 2012 Abstract This GLEP addresses the issue of referencing optional runtime dependencies in Gentoo packages and ebuilds. It does introduce a concept of runtime-switchable USE flags to achieve that goal. Motivation == Optional runtime dependencies are often found in packages installing various scripts (shell, python, perl). These dependencies are not strictly required for the particular package to work but installing them enables additional functionality. Unlike in compiled programs, enabling or disabling those features (dependencies) does not affect the files installed by the package. They can be installed and uninstalled independently of the package, resulting in changes of functionality without a need to rebuild the package. Currently such dependencies are usually expressed only through ``pkg_postinst()`` messages. This forces user to manually install the necessary dependencies, and uninstall them when they are no longer necessary. An another solution is to use regular USE flags. Those flags do not strictly follow the principles of USE flags. They do not affect files installed by the package and are not entirely effective to the package (a disabled feature will still be available if necessary dependency is installed). Additionally, it requires unnecessary rebuilds of the package in order to change the dependencies. Specification = The ebuilds aiming to provide features enabled through optional runtime dependencies should: 1. list the USE flags used for optional runtime dependencies in ``IUSE_RUNTIME`` (and not ``IUSE``); 2. list the necessary runtime dependencies in the ``SDEPEND`` variable. Additionally, the ebuilds must obey the following rules: 1. flags listed in ``IUSE_RUNTIME`` must not be listed in ``IUSE``, 2. flags listed in ``IUSE_RUNTIME`` can be referenced in ``SDEPEND`` and ``REQUIRED_USE`` variables, 3. flags listed in ``IUSE_RUNTIME`` must not be referenced in phase functions, other dependency variables, ``LICENSE`` or ``SRC_URI``, 4. flags listed in ``IUSE_RUNTIME`` can be referenced through USE dependencies by other packages' ``DEPEND``, ``RDEPEND`` and ``PDEPEND``. However, it is not allowed to request disabling those flags (only ``[flag]`` and ``[flag?]`` forms are allowed), 5. flags listed in ``IUSE_RUNTIME`` can be referenced through ``has_version`` and ``best_version`` yet the caller must not rely upon those flags being disabled. The package manager should treat flags listed in ``IUSE_RUNTIME`` as regular USE flags, except for the following: 1. enabling or disabling any of the flags must not involve rebuilding the package, 2. it should be possible for a package manager to change those flags on a installed package without using the original ebuild [1]_, 3. when queried on a installed package, the package manager must consider a particular flag enabled only if its dependencies are satisfied already [2]_, 4. the flags may be listed in the visual output in a distinct way to inform the user that they affect runtime dependencies only. .. [1] The package manager has to ensure that all relevant information is stored in the installed package metadata. .. [2] The result of this check can be cached when updating the metadata of installed package, and it is not strictly required that a package manager must ensure that the dependency graph is still consistent afterwards. Rationale = The proposed solution tries to solve the issue of handling runtime dependencies while reusing the existing infrastructure. Most importantly, users will be able to reuse the existing tools and configuration files to enable and disable optional runtime and build-time dependencies alike. The remaining reused features include: - dependency syntax (USE-conditionals), - ability to use ``REQUIRED_USE``, USE dependencies, - ability to describe flags in `metadata.xml`, - global flag names (and descriptions). Alternative proposed solution involved creating a flag-less ``SDEPEND`` variable. That proposition had the following disadvantages: -
[gentoo-dev] [RFC] Initial python-r1.eclass & distutils-r1.eclass
Hello,
Instead of the floating patches and p-d-ng modifications I sent
earlier, here are the two complete (so far, well, initial :P) eclasses
for review.
They are designed as 'mostly' drop-in python-distutils-ng replacement.
--
Best regards,
Michał Górny
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: python-r1
# @MAINTAINER:
# Python herd
# @AUTHOR:
# Author: MichaŠGórny
# Based on work of: Krzysztof Pawlik
# @BLURB: A common, simple eclass for Python packages.
# @DESCRIPTION:
# A common eclass providing helper functions to build and install
# packages supporting being installed for multiple Python
# implementations.
#
# This eclass sets correct IUSE and REQUIRED_USE. It exports PYTHON_DEPS
# and PYTHON_USEDEP so you can create correct dependencies for your
# package easily. It also provides methods to easily run a command for
# each enabled Python implementation and duplicate the sources for them.
case "${EAPI}" in
0|1|2|3)
die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
;;
4)
# EAPI=4 needed for REQUIRED_USE
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
;;
esac
# @ECLASS-VARIABLE: _PYTHON_ALL_IMPLS
# @INTERNAL
# @DESCRIPTION:
# All supported Python implementations, most preferred last.
_PYTHON_ALL_IMPLS=(
jython2_5
pypy1_8 pypy1_9
python3_1 python3_2
python2_5 python2_6 python2_7
)
# @ECLASS-VARIABLE: PYTHON_COMPAT
# @DESCRIPTION:
# This variable contains a space separated list of Python
# implementations a package supports. It must be set before
# the `inherit' call. The default is to enable all implementations.
#
# PYTHON_COMPAT can be either a scalar or an array. If it's a scalar,
# the eclass will implicitly convert it to an array.
: ${PYTHON_COMPAT:=${_PYTHON_ALL_IMPLS[@]}}
# @ECLASS-VARIABLE: PYTHON_REQ_USE
# @DEFAULT_UNSET
# @DESCRIPTION:
# The list of USEflags required to be enabled on the chosen Python
# implementations, formed as a USE-dependency string. It should be valid
# for all implementations in PYTHON_COMPAT, so it may be necessary to
# use USE defaults.
#
# Example:
# @CODE
# PYTHON_REQ_USE="gdbm,ncurses(-)?"
# @CODE
#
# Will cause the Python dependencies to look like:
# @CODE
# python_targets_pythonX_Y? (
# dev-lang/python:X_Y[gdbm,ncurses(-)?] )
# @CODE
# @ECLASS-VARIABLE: PYTHON_DEPS
# @DESCRIPTION:
# This is an eclass-generated Python dependency string for all
# implementations listed in PYTHON_COMPAT. It should be used
# in RDEPEND and/or DEPEND like:
#
# @CODE
# RDEPEND="${PYTHON_DEPS}
# dev-foo/mydep"
# DEPEND="${RDEPEND}"
# @CODE
# @ECLASS-VARIABLE: PYTHON_USEDEP
# @DESCRIPTION:
# This is an eclass-generated USE-dependency string which can be used to
# depend on another Python package being built for the same Python
# implementations. It should be used like:
#
# @CODE
# RDEPEND="dev-python/foo[${PYTHON_USEDEP}]"
# @CODE
PYTHON_COMPAT=( ${PYTHON_COMPAT[@]} )
_python_set_globals() {
local flags=( "${PYTHON_COMPAT[@]/#/python_targets_}" )
local optflags=${flags[@]/%/?}
IUSE=${flags[*]}
REQUIRED_USE="|| ( ${flags[*]} )"
PYTHON_USEDEP=${optflags// /,}
PYTHON_DEPS=
local i
for i in ${PYTHON_COMPAT[@]}; do
local d
case ${i} in
python*)
d='dev-lang/python';;
jython*)
d='dev-java/jython';;
pypy*)
d='dev-python/pypy';;
*)
die "Invalid implementation: ${i}"
esac
local v=${i##*[a-z]}
local usestr
[[ ${PYTHON_REQ_USE} ]] && usestr="[${PYTHON_REQ_USE}]"
PYTHON_DEPS+=" python_targets_${i}? (
${d}:${v/_/.}${usestr} )"
done
}
_python_set_globals
# @FUNCTION: python_get_PYTHON
# @USAGE:
# @DESCRIPTION:
# Get the Python executable name for the given implementation. Please
# note that this this function returns the 'basename' only.
# If using it for a hashbang, please use #!/usr/bin/env.
python_get_PYTHON() {
local impl=${1/_/.}
case "${impl}" in
python*|jython*)
echo ${impl}
;;
pypy*)
echo pypy-c${impl#pypy}
;;
*)
die "Invalid argument to python_get_PYTHON: ${1}"
;;
esac
}
# @FUNCTION: python_copy_sources
# @DESCRIPTION:
# Create a single copy of the package sources (${S}) for each enabled
# Python implementation.
python_copy_sources() {
local impl
local bdir=${B
