Open dezgeg opened 7 years ago
Or maybe just document to not forget about fixupPhase?
I'm very in favour of this!
As an author of osmctools
expression I want to note that at least some
of those uses are legit.
I agree that adding fixupPhase
there (or pretty much to any expression
lacking it) wouldn't hurt.
But I think that explicitly disabling all the phases when you don't want them is a pain in the ass (and would require a lot of maintenance when stdenv adds a phase).
I'd prefer a solution where hooks and fixupPhase
are not "phases" but
some special things you are not supposed to touch. To me they seem to be
more of "prePhases" and "postPhases" things than "phases".
If touching phases directly is deprecated, how would you go about reordering phases without manually touching the phases attribute? I'm thinking of things like python where checkInstall does tests before the installation phase, but a test requiring calling of an exucution a shell command generated (and wrapped) in the install phase that isn't created until after the install phase?
Not doable for 18.09.
Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:
If this list is remade, Xpra should be removed
I marked this as stale due to inactivity. → More info
I marked this as stale due to inactivity. → More info
still relevant
I would suggest a whitelist and a blacklist. Or inclusive phase list and an exclusive phase list. One overrides the other.
@Stunkymonkey I suggest you batch your changes into maybe 10-20 packages per PR. You can still have individual commits per package, but title the PR treewide: remove phases
or similar.
i would like to pack them into one PR, but i feel that the merging process would just get delayed for many days. this way it is nice and separate, but the downside are the notifications you receive.
We should either undocument phases
Nope.
First, many automated packages use it as a low-level structure. If they are still present, then they should stay documented even if they are not recommended for high-level human-generated packages.
Second, undocument things is an horrendous practice. An undocumented piece in a code makes it harder to understand, and it can become frustrating for a newcomer.
or at least write that it's a bad idea
It is the best course of action indeed.
i would like to pack them into one PR, but i feel that the merging process would just get delayed for many days.
Pack 10 or 20 per round. Treewide modifications don't need to be so treewide.
Pack 10 or 20 per round. Treewide modifications don't need to be so treewide.
if you have a look at the latest PRs you see improvements. I hope that is okay for everybody.
this issue progressed very well in the last weeks, due to the nice help reviewers provided to me.
i am currently short on time. So I hope someone else is interested in closing this issue and could continue the work.
the current progress:
$ rg 'phases = ' pkgs/ --files-with-matches | wc -l
67
could someone tell where phases = ...
is wanted? or is the goal to remove it in the future?
the remaining packages with rg 'phases = ' pkgs/ --files-with-matches | sort
:
The Elisp packages are script-generated. The only useful way to "get rid of phases
" in them is to modifying the scripts that generate them. For now, I think they can be ignored.
The other I don't know for sure, but should be safe to modify them.
if the last two PRs get merged I do not know what to do next here. There are now "38" (will be "36" hopefully) files left.
Most of them require more expertise then I have or are not free. And someone a darwin
system for a few files.
This issue is close to being fixed. Maybe this is something, that is wanted for release 21.11
So please continue the work
NOTE: srcOnly
relies on phases = [...]
.
I don't think that is an exception. It can also just disable buildPhase
I don't think that is an exception. It can also just disable buildPhase
...and configurePhase
, and checkPhase
, and fixupPhase
, and installCheckPhase
, and distPhase
? phases = [...];
is a lot clearer and robust.
I tend to disagree.
If there are too much phases to disable, just use a custom build.sh
script.
We're talking in the context of srcOnly
, where that is not feasible.
Doing stuff like
phases = [ "unpackPhase" "buildPhase" "installPhase" ];
is a bad idea, because:fixupPhase
are almost always forgotten, leading to things like:patchelf --shrink-rpath
autoreconfHook
which appends topreConfigurePhases
)We should either undocument
phases
or at least write that it's a bad idea, and replace all the following with properdontBuild
etc. flags: