[doc] Remove references to "Nix" in "How to build locally..." #11008
Conversation
|
@simonmar: thank you for the PR. Please feel free to set the merge_me label to start the ~2 days merging process. |
There was a problem hiding this comment.
Should we rename both files so that the URL doesn't mention Nix as well?
There was a problem hiding this comment.
If we do this, then perhaps we should rename it in the code. The options from the Distribution.Client.NixStyleOptions module (nixStyleOptions and NixStyleFlags) should be renamed to V2Options and V2Flags ?
There was a problem hiding this comment.
Touching code is a big can of forms, so, if someone wants to mess with it, I'd suggest to leave it for a separate PR.
There was a problem hiding this comment.
For that matter, touching documentation breaks links. And yeh, renaming functions and modules causes big API breaks (granting that it's the cabal-install API which is less widely used than Cabal/Cabal-syntax).
There was a problem hiding this comment.
touching documentation breaks links
there are ways to put redirects, right?
There was a problem hiding this comment.
https://pypi.org/project/sphinx-reredirects/ looks interesting?
There was a problem hiding this comment.
Option B is my suggestion. I can't see details of option A since you sent an image instead of a URL that would let me expand the hidden part of the example.
There was a problem hiding this comment.
I don't think GitHub Copilot (which is what I used here) allows shareable links. The listing for .readthedocs.yml is:
version: 2
sphinx:
configuration: docs/conf.py
redirects:
- type: page
from: /name.html
to: /new-name.html
I wasn't able to quickly corroborate that this is indeed a working solution (after all, AI can hallucinate).
FTR I'm impartial to what solution we pick, but it'd be good to pick and implement one: I'm still seeing the fallout after the renaming of cabal-file and cabal-project pages.
There was a problem hiding this comment.
I figured as much; that's why I'm wary of making it worse.
|
|
||
| In cabal-install 2.0 and above, Nix-style local builds also take advantage of a | ||
| new Cabal library feature, `per-component | ||
| builds <https://github.com/ezyang/ghc-proposals/blob/master/proposals/0000-componentized-cabal.rst>`__, |
There was a problem hiding this comment.
So, we lose this link in this patch... It may be good to think about preserving it in some form. I don't think there's a comparable explanation in the manual itself currently.
There was a problem hiding this comment.
What are the benefits of the user seeing a link about how cabal worked more than 10 years ago?
As we can see, the proposal itself is a transition from the old configure to the new one + adding components.
There was a problem hiding this comment.
Full disclosure: I didn't read the proposal too closely. My cursory look at it suggested that it describes things that are still relevant today. You seem to be of different opinion. Unless one of us finds energy to argue the point properly, with links to code and stuff, we can't solve this disagreement.
But maybe we don't have to agree because the proposal was archived as https://github.com/haskell/cabal-proposals/blob/master/proposals/componentized-cabal.rst which is more visible, so I'm less concerned about the removal of this link from the manual. Unless someone feels like fixing it, I lean towards letting this issue go. To be clear, fundamentally, I don't agree that it's a good idea to remove it, but I think that it's less bad now.
See #6105
Please read Github PR Conventions and then fill in one of these two templates.