This should be something that looks same across the tree, and IMHO we shouldn't allow random eclasses or ebuilds define their own format. It's a job for the Package Manager, and if it's not coming from there, it should at least match it. python.eclass: _python_set_color_variables() { if [[ "${NOCOLOR:-false}" =~ ^(false|no)$ ]]; then _BOLD=$'\e[1m' _RED=$'\e[1;31m' _GREEN=$'\e[1;32m' _BLUE=$'\e[1;34m' _CYAN=$'\e[1;36m' _NORMAL=$'\e[0m' else _BOLD= _RED= _GREEN= _BLUE= _CYAN= _NORMAL= fi } Example of `emerge -C gnofract4d` when it hits pkg_postrm (cleaning up byte-compiled python). <snip> [32;01m*[0m [1;34m<<< /usr/lib64/python2.6/site-packages/fractutils/get.py[co][0m [32;01m*[0m [1;34m<<< /usr/lib64/python2.6/site-packages/fractutils/formulas.py[co][0m [32;01m*[0m [1;34m<<< /usr/lib64/python2.6/site-packages/fractutils/test_flickr.py[co][0m [32;01m*[0m [1;34m<<< /usr/lib64/python2.6/site-packages/fractutils/makemap.py[co][0m [32;01m*[0m [1;36m<<< /usr/lib64/python2.6/site-packages/fractutils[0m ^ Unstandard colors, not with-in the Gentoo format. [32;01m*[0m Updating desktop mime database ... [32;01m*[0m Updating shared mime info database ... </snip>
Bolded red from deprecation warning (sci-libs/vtk): [31;01m*[0m [31;01m*[0m [1;31mDeprecation Warning: python_version() is deprecated and will be banned on 2010-07-01.[0m [31;01m*[0m [1;31mUse PYTHON() instead of python variable. Use python_get_*() instead of PYVER* variables.[0m [31;01m*[0m
yes, that function needs to be tossed. we have a color standard integrated with portage that allows people to customize for their own preferences. this completely ignores that for literally 0 gain.
Yes, that function, and everything that uses the colors throughout the eclass need to go. Let the package manager format the text and display everything. Python: could you please let us know if you are going to work on this, or do you wish for us to fix it for you? Thanks
Colors have been successfully used in some functions for a long time. _python_set_color_variables() has been recently created to avoid setting color variables separately in many functions. We might remove colors from deprecation warnings. In case of python_mod_cleanup(), we would need to find a good (preferably locale-independent) way (with output with constant indentation) of distinction of directories and regular files.
i really dont know what you're trying to say. i'll phrase it simply: stop trying to do all your own colorization. use the standard functions to do output (einfo/ewarn/eerror/etc...).
I think that python_mod_cleanup() could use echo instead of einfo. Colors in python_execute_*() should not be changed (at least when used with echo).
I committed the removal of custom colors with deprecation notices earlier today (unaware of this bug even existing) based on IRC discussions yesterday. The colors can of course be continued to be used in outputs that are purely build time outputting and not for communicating things for users like what cmake builds do.
This seems to be back, and the colors need to be removed.
unless i missed something, this is still broken, so i'll go ahead and fix it for you this weekend
@spanky, please ensure it's testing for NOCOLOR (if it survives) assumes coloring is disabled if the var isn't set also... stupid code forces coloring in pkgcore always.
Created attachment 239195 [details, diff] python.eclass.patch this is what i plan on committing. there is no NOCOLOR usage.
(In reply to comment #11) > Created an attachment (id=239195) [details] > python.eclass.patch > > this is what i plan on committing. there is no NOCOLOR usage. Convert _python_set_color_variables to a warning please, one that does nothing- I suspect overlays may have some usage of it. distutils.eclass in gentoo-x86 definitely does (should be updated the same). Might want to convert that NEED_PYTHON echo'ing to >&2 btw, although that also has it's own potential issues. Either way, thanks, this has been a serious annoyance to pkgcore for a long while.
Created attachment 239203 [details, diff] distutils.eclass.patch didnt know it was externally used. this updates distutils.eclass too. no need to keep the func around as distutils.eclass only uses it in src_* funcs, not any pkg_* funcs.
Colors must be shown for people, who want to see them. I will use PYTHON_COLORS variable.
Reassigning to maintainers.
(In reply to comment #14) > Colors must be shown for people, who want to see them. I will use PYTHON_COLORS > variable. Dude, just drop it. If this were your personal playpen, I'd say go nuts, but it's not. The end result of those logs can wind up in devs mailboxes (looking might ugly), the implementation has no way of knowing if the PM is writing to a pipe (meaning term codes can't be used in e* funcs) or a tty, and most importantly *everyone is telling you knock that shit off*, both from a QA/policy and PM standpoint.
mike, the patches look good. please do commit them.
You cannot remove optional feature, which helps other developers develop ebuilds. Colors are now disabled by default and can be enabled by setting PYTHON_COLORS="1" (usually in /etc/make.conf). If somebody doesn't want to have color codes in logs, then he won't set PYTHON_COLORS variable. Colors are no longer used with einfo/elog/ewarn/eerror.
you were directed in the ml to work w/ betelgeuse for eqawarn on this... not just slip the unused ewarn in...
