Comments (31)
Okay, so I confirmed that 3.12 branch works fine. I also bisected master
and tracked it down to #9565. (Which @alt-romes already guessed on Matrix.) We're now trying to figure out how best to proceed.
To summarize: we started using relative imports in cabal's source tree, which are relative to the wrong directory in 3.10.
I did not determine when the relative-directory bug was fixed on master
, and don't plan to do so unless a decision is reached to release an update in the 3.10 series. (This is unlikely to happen, and if it did would be after 3.12.1.0 is released since that's our current priority after getting Cabal 3.12.0.0 out for ghc 9.10.)
from cabal.
You are right that HEAD appears to work.. but you shouldn't require HEAD cabal-install to develop cabal-install!
No, but
Can the patch responsible please be reverted quickly?
implies it, especially if you're talking about 3.10.2.1.
from cabal.
@philderbeast turns out to be on holidays, so let's handle this ourselves. If making the reverts turns our relatively painless, I'd opt for that and I take personal responsibility for the decision to revert (and I will press the big red button and then remember to merge these PRs back again in a year). Otherwise, if reverting and re-applying the conflicting PRs is particularly messy, let's try workarounds, e.g., "some kind of git clone hook to automatically substitute SOMETHING for $(pwd) in the cabal.project files". If Phil returns before we are done, I'd love to get his input, but this it git, whatever gets reverted can be rereverted, so let's not spoil Phil's holidays by blocking any design or decision on him. If there is a good workaround in 2 weeks, we can re-revert in 2 weeks.
from cabal.
(copied from Matrix)
I vaguely recall some early Unixy tool (possibly mh
) where @
was a symlink in every directory pointing at a central resource, for convenience. Would it be possible (given, for example, the limitations of "symlinks" on Windows) to use something like this to ensure that a path relative to that within our source tree always points to the same thing?
ANSWER: apparently not. hlint
recursively scans the tree and really dislikes the symlinks.
EDIT: a modified form didn't cause an infinite loop, but hlint
got really slow. Dropped it.
from cabal.
I'm back and will look at this today.
from cabal.
@philderbeast: thank you!
BTW a detail to take care of when we re-instate the PR: the bootstrap-regenerating project file (not bootstrap-building for tests) can't have tests in it or the build plan gets too large, so this file has just been added in #9897 (edit: just merged):
Which unfortunately also duplicates index-state --- but we may have no choice in that until all reasonably new cabal binaries have correct relative path handling.
from cabal.
That's a @philderbeast's patch, I think?
from cabal.
I don't seem to be able to reproduce this locally with a just-built HEAD
.
hilfy «cabal:master» Z$ cp $(cabal list-bin cabal) ~/.local/bin/cabal-head
Warning: this is a debug build of cabal-install with assertions enabled.
hilfy «cabal:master» Z$ (builtin cd Cabal; cabal run -- cabal-install:cabal --help)
Warning: this is a debug build of cabal-install with assertions enabled.
Command line interface to the Haskell Cabal infrastructure.
See http://www.haskell.org/cabal/ for more information.
Usage: cabal [GLOBAL FLAGS] [COMMAND [FLAGS]]
(...)
Your command also completes successfully. (I was going to bisect it.)
from cabal.
I am using
cabal --version
cabal-install version 3.10.2.1
compiled using version 3.10.2.1 of the Cabal library
You are right that HEAD appears to work.. but you shouldn't require HEAD cabal-install to develop cabal-install!
from cabal.
Still happens with 3.10.3.0.
from cabal.
@geekosaur Normal development practice is regressed because the current state of the repo doesn't work with existing developer workflows with a released version of cabal-install. (Arguably an even more critical reason to revert than a broken release)
from cabal.
It's already reverted. What do you want, that we retroactively re-release 3.10.2 without whatever it was?
from cabal.
@mpickering: would marking 3.10.2.1 deprecated help? I'm confused. [Edit: I misread the comments]
from cabal.
[Edit: this was wrong again, though less so. See another take in the next comment.]
Oh, I mis-read. You said "Still happens with 3.10.3.0". So the current stable cabal is broken in this way. So what @mpickering would need is porting the fix to the 3.10 branch (unless already ported and unless it changes the API) and releasing 3.10.4.0. Which ticket is it and which PR fixes it?
I'm afraid, unless somebody steps up, we don't have the resources to release 3.10.4.0 for a couple more months and by then 3.12.1.0 with cabal-install should be released, which contains the fix (I hope).
For now, is there an older version of cabal that doesn't have this bug? 3.10.1.0? 3.8.*?
from cabal.
@alt-romes helped me understand what's probably going on:
Probably, HEAD's dev configuration (cabal files, project files, whatever) uses a new feature that cabal 3.10 does not yet support. If so, that's a case of a too short transition period between introducing a new feature and requiring it for building the project. And so, it should be reverted temporarily and brought back when cabal 3.12 or cabal 3.14 is released (maybe the latter given the damage done already).
The question is what this feature is exactly and how to revert it without breaking things (or even, potentially, with fixing bugs that the new feature fixed, in a more conservative way, for now --- but let's hope that's not the case and reverting is enough).
from cabal.
Copying from the channel:
<sclv> could be different semantics for relative paths is project import imho
from cabal.
@philderbeast: you improved these or related things so you may have an inkling what's going on. Would you venture a guess?
from cabal.
@philderbeast: we are discussing this in the channel right now, but I can't remember your Matrix nick. In any case, please feel free to read the channel backlog.
from cabal.
BTW, I was wrong saying (on the Matrix channel?) that reverting the PR could cause problems backporting things to branch 3.12 --- the PR is not on branch 3.12, so that would actually get the two branches closer.
from cabal.
BTW, there's a lot of great commits in that PR, e.g., removing many unused files. Yes, it may turn out in the future we need one of these files, but I'd rather keep the commits and only revert the ones that depend on the relatives paths functionality that we can't provide in the already released cabal-install 3.10 binaries. Or maybe just copy-paste all the common project file parts instead of including them. I wonder if we'd end up with many copies of the index state stamp. That would be a major nuisance.
from cabal.
You are right that HEAD appears to work.. but you shouldn't require HEAD cabal-install to develop cabal-install!
If released cabal-install
versions have a bug what is the problem with using HEAD cabal-install
? Is it to avoid the build and install time cost?
$ git rev-parse HEAD
3395fa138492f4006b6be45a0b95863da60f18a2
$ cabal clean
$ rm -r ~/.cabal/store/ghc-9.8.2
$ time cabal install cabal-install:exe:cabal --overwrite-policy=always
...
Resolving dependencies...
Build profile: -w ghc-9.8.2 -O1
In order, the following will be built (use -v for more details):
- Cabal-3.13.0.0 (lib) (requires build)
- cabal-install-solver-3.13.0.0 (lib) (requires build)
- cabal-install-3.13.0.0 (lib) (requires build)
- cabal-install-3.13.0.0 (exe:cabal) (requires build)
...
________________________________________________________
Executed in 163.07 secs fish external
usr time 221.26 secs 637.00 micros 221.26 secs
sys time 12.84 secs 129.00 micros 12.84 secs
from cabal.
The nightly also works fine; instructions for getting it are in the README.
from cabal.
If released cabal-install versions have a bug what is the problem with using HEAD cabal-install? Is it to avoid the build and install time cost?
I don't think so. It think the biggest problem is surprise and then churn. If you are new to cabal, you may spend a lot of time troubleshooting your setup before somebody remembers to ask "of course you are not using the stable cabal release?". Then let's suppose you spawn VMs for testing. First, something breaks and you need to diagnose. Then you discover it's this known problem and so from now on, in each VM instance you need to compile, copy or download a cabal version. Developer's comfort matters a lot.
from cabal.
surprise and then churn
I'd suspected as much. Wouldn't a lighter weight fix be prominent contributor notes about known problems and workarounds. I feel bad about adding a workaround project in #9923 and would rather it not be merged.
from cabal.
Now that you say so, indeed remembering (and initially, knowing) to add --project-file=cabal.workaround.project
to each invocation of run Cabal-tests:parser-tests
is not substantially more light weight that copying a nightly cabal binary to, say, a VM.
Regarding well written and advertised "known problems and workarounds" section in CONTRIBUTING.md, that would be good, but even better would be an empty "known problems and workarounds" section. :)
It's really a pity one can't hardwire in parser-tests.cabal
to use cabal.workaround.project
by default, but then, it would be one more place where users can complicate things, making their and our diagnosis of cabal problems harder.
Are we out of plausible workarounds? If so, how about reverting? As I've written above, this is such a valuable PR that it would be best to revert it selectively, but we probably can't avoid the worst outcomes, such as duplicating index state stamps (which has already happened due to bootstrap generation in another PR). In a year or a half we can deduplicate things again, maybe including the bootstrap stamp.
Thoughts?
from cabal.
Are we out of plausible workarounds?
The workaround project would get picked up automatically if named Cabal-tests/cabal.project
. This would serve as an invisible crutch the older cabal-install
versions can use (and the HEAD one too).
Can we deprecate the older versions as far as their use in cabal development goes? They're broken for 2+ hop project imports that include relative paths, aren't they?
I'm really hoping that we can clean up our use of projects further, #9565 (comment).
from cabal.
Can we deprecate the older versions as far as their use in cabal development goes?
Absolutely. Given how broken they are, half a year (as opposed to a year, I'd reflexively propose in such cases) deprecation cycle sounds reasonable.
They're broken for 2+ hop project imports that include relative paths, aren't they?
I think they are. Thank you for helping to discover that and fixing in another PR --- both unwittingly from what I gather. :D
My idea is that while we in the deprecation period for cabal development with cabal-install 3.10, we should refrain from using the features that are broken in 3.10 and that were, apparently, not widely enough used to cause problems beforehand.
I'm really hoping that we can clean up our use of projects further, #9565 (comment).
That would be amazing. And it's great we (you) are doing this gradually, letting the related errors emerge in smaller batches rather than all at once.
So, shall we temporarily revert the part of the refactor that 3.10 can't handle?
from cabal.
We are in a short lull between releses 3.12.0.0 and 3.12.1.0, so let's try to resolve this one way or the other. Are there any objections to temporarily reverting the problematic part of #9565? Assuming there are none, would somebody offer to do the revert PR? I can help by reviewing and pressing the merge button myself.
from cabal.
Normal development practice is regressed
@mpickering could you expand on what you mean by "normal development practice" please? Are you referring to development-in-general normal, developing-on-NixOS normal (where adhoc installing may be harder) or Cabal-specific-development normal?
Do we recommend a version of cabal-install
for development? If not, cabal install cabal-install:exe:cabal --overwrite-policy=always
should be the recommended version, shouldn't it? That CONTRIBUTING.md leads with building Cabal for hacking suggests to me that I should install cabal-install
from HEAD or use cabal run -- cabal-install:exe:cabal etc
when hacking.
Note
There is no problem building the project using older cabal-install
versions that choke on imports when calling cabal run
from a subdirectory of the project.
from cabal.
I expect that developers provision cabal-install
from their system package manager therefore the code base should work with at least the most recent released version of cabal-install
. When this error was reported I was using the most recent version of cabal-install and it couldn't perform certain tasks in the project (accepting tests in my case).
If this isn't the widespread opinion, then feel free to close the ticket but it seems quite a basic requirement of a project to me.
from cabal.
Thank you for your input. However, I can see no volunteers to revert parts of the PR (and I think reverting it whole would be an overkill at this point) so maybe we could just add a note to CONTRIBUTING.md and to cabal-install 3.12 release notes recommending at least 3.12 for cabal development, with a link to this very issue? Objections? Volunteers (but if none and no objections, I'd do this myself)?
from cabal.
Related Issues (20)
- Cabal-3.12.0.0 passes include dirs to GHC in a new order HOT 6
- build-tool-depends in Cabal regresses ghc ability to build from source distribution HOT 5
- Cabal external command requires typing Return to exit HOT 1
- Support monitoring directory recursive globs
- cabal init fails if git is not installed HOT 5
- Failure to find a program produces an incomprehensible error
- Encountered possible bug during building rpki-prover HOT 14
- Using Setup.hs build --with-ghc looses configure --ghc-option HOT 1
- Conditions don't work with flags HOT 2
- Are we validating `ghc-options` in `.cabal` files? HOT 4
- Do not pass environment variables to `happy`/`alex`, or at least allow a way to filter HOT 2
- Is the `CabalParsing` class necessary? HOT 2
- Changelog for Cabal 3.12 is missing mention of error codes
- Amend non-reinstallable packages list HOT 6
- "Use of GHC's environment variable GHC_PACKAGE_PATH is incompatible with Cabal" when running `Setup.hs test` should be a warning, not an error HOT 4
- Remember "Choose a language for" choice on `cabal init` HOT 4
- Favour non-preferred versions over deprecated versions
- [RFC] Revive cabal sandboxes (UX) HOT 2
- perf: verifyFetchedTarball called once for each package from a remote repository
- Come up with a way to build documentation for a package without rebuilding a lot HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cabal.