<@floppym> I don't really care for this strange manipulation of ${S} all over the place, however. <@floppym> We should really be using a different variable I think.
Mike: I think that using ${S} makes thing cleaner - it's always S, you don't have to check what new name this eclass uses. Is there anything specific that you don't like how S get's changed?
At a technical level, PMS allows S to be reassigned only if it has not been assigned as a global (outside of a function). I don't know of a sane way to deal with this inside the eclass. Personally, I always think of S as a constant; it is assigned once in global scope and never changes. I find it a bit disorienting to start in one place in src_prepare, but start in another place in src_install.
S is "constant" with regards to implementation. I find it consistent - it's S, the place where sources are, ruby-ng eclass does the same manipulation of S by the way. Is it ok if I close this bug then?
Created attachment 310649 [details, diff] patch What if we make S local in _python-distutils-ng_run_for_impl? That would make S behave consistently between src_compile and src_install. That also allows us to eliminate the reset in python-distutils-ng_src_install. See patch.
(In reply to comment #4) > Created attachment 310649 [details, diff] [details, diff] > patch > > What if we make S local in _python-distutils-ng_run_for_impl? That would > make S behave consistently between src_compile and src_install. > > That also allows us to eliminate the reset in > python-distutils-ng_src_install. > > See patch. I think it's a cosmetic change, feel free to commit if you care enough and lets close this bug.
It is not just cosmetic; without this change, S has a indeterminate value upon entry to src_install due to being manipulated by src_compile. I have committed the change.
