| Summary: | python-distutils-ng: would use a function to generate USEdeps | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Eclasses | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | enhancement | CC: | skrattaren |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Test case for calling function in DEPEND
Test case for using a variable in DEPEND |
||
Like I've pointed out on ML: feel free to implement. (In reply to comment #0) I actually like the approach Arfrever has taken. He has a function called python_abi_depend. You pass a package atom to this function, and it echoes a use-dep back. For example, if you have this: DEPEND="$(python_abi_depend dev-python/foo)" This would generate a dependency string like this: DEPEND="dev-python/foo[python_abis_2.6?,python_abis_2.7?,...]" The function also accepts options to include/exclude certain python abis for each dependency; this is handy since python packages sometimes have different dependencies depending on the python version. (In reply to comment #2) > (In reply to comment #0) > > I actually like the approach Arfrever has taken. He has a function called > python_abi_depend. You pass a package atom to this function, and it echoes a > use-dep back. > > For example, if you have this: > > DEPEND="$(python_abi_depend dev-python/foo)" I really dislike the overhead of function calling here, especially that it's going to happen in the global scope and for a number of packages. I'm afraid it's going to make metadata generation a PITA. I think we should try to keep this simple, or at least provide a simpler variant which would work as well in the most cases. > The function also accepts options to include/exclude certain python abis for > each dependency; this is handy since python packages sometimes have > different dependencies depending on the python version. Unless it outputs a completely different form, I don't think it's actually useful (i.e. like 'python2_6? ( foo/bar[python2_6?] )'). And if the output is actually like that, I think it'd be saner to create another function for that. (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > > I actually like the approach Arfrever has taken. He has a function called > > python_abi_depend. You pass a package atom to this function, and it echoes a > > use-dep back. > > > > For example, if you have this: > > > > DEPEND="$(python_abi_depend dev-python/foo)" > > I really dislike the overhead of function calling here, especially that it's > going to happen in the global scope and for a number of packages. I'm afraid > it's going to make metadata generation a PITA. > > I think we should try to keep this simple, or at least provide a simpler > variant which would work as well in the most cases. You can look at ruby-ng eclass, since our new python-distutils-ng is very close to it. There are functions like ruby_add_bdepend and ruby_add_rdepend for this task. We just can adapt them to python. And since no one complains for ruby, no one will for python. (In reply to comment #4) > You can look at ruby-ng eclass, since our new python-distutils-ng is very > close to it. There are functions like ruby_add_bdepend and ruby_add_rdepend > for this task. We just can adapt them to python. Monkey see, monkey do? > And since no one complains for ruby, no one will for python. Because no-one uses ruby :P. (In reply to comment #5) > (In reply to comment #4) > > You can look at ruby-ng eclass, since our new python-distutils-ng is very > > close to it. There are functions like ruby_add_bdepend and ruby_add_rdepend > > for this task. We just can adapt them to python. > > Monkey see, monkey do? Nope. We already have one working approach, no need to invent something new. > > And since no one complains for ruby, no one will for python. > > Because no-one uses ruby :P. There are still lots of ruby ebuilds in tree invovled in metadata generation. (In reply to comment #3) > I really dislike the overhead of function calling here, especially that it's > going to happen in the global scope and for a number of packages. I'm afraid > it's going to make metadata generation a PITA. I would prefer not to have an argument about performance without any numbers to justify either position. My guess is that it will make a relatively small difference, but again, I have no numbers and do not intend to waste time gathering them. > Unless it outputs a completely different form, I don't think it's actually > useful (i.e. like 'python2_6? ( foo/bar[python2_6?] )'). And if the output > is actually like that, I think it'd be saner to create another function for > that. Thinking this out, foo/bar[python2_6?] is equivalent to this: python2_6? ( foo/bar[python2_6] ) !python2_6? ( foo/bar ) We only want the first line in cases where a dependency is needed only for a subset of python targets. Also, I personally prefer the concept of a function that echos dependency atoms over the ruby approach of appending to specific variables. The method used by python_abi_depend can be used for 3 [PR]DEPEND variables, or any other variable the ebuild author happens to use (like COMMON_DEPEND). (In reply to comment #8) > Also, I personally prefer the concept of a function that echos dependency > atoms over the ruby approach of appending to specific variables. > > The method used by python_abi_depend can be used for 3 [PR]DEPEND variables, > or any other variable the ebuild author happens to use (like COMMON_DEPEND). And also it makes it possible to do thinks like DEPEND="python? ( $(python_abi_depend) )" (In reply to comment #7) > (In reply to comment #3) > > I really dislike the overhead of function calling here, especially that it's > > going to happen in the global scope and for a number of packages. I'm afraid > > it's going to make metadata generation a PITA. > > I would prefer not to have an argument about performance without any numbers > to justify either position. My guess is that it will make a relatively small > difference, but again, I have no numbers and do not intend to waste time > gathering them. $ bash a.bash real 0m7.251s user 0m1.869s sys 0m3.566s $ bash b.bash real 0m0.236s user 0m0.231s sys 0m0.005s a.bash 'simulates' 1000 runs with 5 deps; 5 calls of function which just outputs stuff, the same stuff over and over again. b.bash 'simulates' 1000 runs with 5 deps; 1 call of function to set variable ('source eclass') + 5 uses of that variable. Created attachment 313217 [details]
Test case for calling function in DEPEND
Created attachment 313219 [details]
Test case for using a variable in DEPEND
(In reply to comment #10) Thanks for that. Thinking about it, I guess it does make sense to "cache" the most common case in a variable; otherwise we are just regenerating the same string over and over. So maybe a global variable for the common case, and a function to deal with the others? (In reply to comment #13) > (In reply to comment #10) > > Thanks for that. > > Thinking about it, I guess it does make sense to "cache" the most common > case in a variable; otherwise we are just regenerating the same string over > and over. > > So maybe a global variable for the common case, and a function to deal with > the others? That's what I said. But I'd just start with the variable, and wait with the function till we know best what it needs to deal. The eclass is no longer developed. |
Writing USE-deps by hand is quite annoying. Especially that they have to be repeated for every Python version in PYTHON_COMPAT. We should probably provide a helper function to handle that. Or just a dumb variable like ${PYTHON_TARGET_USE}. i.e.: RDEPEND=">=app-portage/gentoopm-0.2.1[python_targets_python2_6?,python_targets_python2_7?,...]" to: RDEPEND=">=app-portage/gentoopm-0.2.1[${PYTHON_TARGET_USE}]"