-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Local dependency paths are incorrect when packages.dhall
is in another directory
#244
Comments
Hi @elliotdavies! I am aware of this problem since a while, but I put off writing down an explanation until now - the reason is that I was not sure how much of an impact this had outside of my own usage, so I focused on other things. The first issue that uncovered this problem is #172 - by itself it's not a big deal to implement, but it's blocked until we fix this "path problem" The problem is the following:
A possible solution for this would be to:
Does this make sense to you? Implementing this would require mostly working with unevaluated Dhall AST (as opposed to evaluated one which gets just read into Haskell types), which we already do quite a bit, e.g. take a look at the Config and in the PackageSet modules. |
Is the problem not that the second argument to My first thought was that the |
@jmackie the problem is indeed that the path is stringy, but also that it refers to the folder the |
Nah not really, but you got this so I'll pipe down 💪 |
@jmackie I think if you run @elliotdavies repro it might get clearer: basically the paths that you list in the So e.g. if you had a |
@f-f Just realised I never replied to this - thanks for the advice, I will have a go at fixing this when I next get the chance! |
There are some new Dhall features in the pipeline that might help with this - see: dhall-lang/dhall-lang#71 |
@Dretch great find! I even commented on that issue, but I totally forgot about it 😄 That looks exactly what we'd need in this case. More specifically we'd want Dhall to resolve relative paths to absolute ones based on where the imported file is, not on what the I'll take a look at standardizing it, as a lot of the work for it is already in place |
Update:
|
Update: the standardization in dhall-lang/dhall-lang#585 has been merged, and I opened a PR to implement it in dhall-lang/dhall-haskell#1019 After that's merged we'll need to wait for a new release, but we can start the migration in |
@f-f Awesome, I've been following your progress 😀 Thanks for working on it! |
Update: turns out we might not need to change (@elliotdavies you can probably test that branch already and see if it works for you - please read through the changes first, as it might be broken/dangerous - I just tested it on our monorepo and it seems to work: KSF-Media/affresco#136) |
This changes how local packages are specified in the `packages.dhall` This is a breaking change, because the old local syntax will now error out Taking the README example, we go from this: ``` let additions = { foobar = mkPackage (../foobar/spago.dhall).dependencies "../foobar" "local-fix-whatever" } ``` to this: ``` let additions = { foobar = ../foobar/spago.dhall as Location } ``` This means a couple of things: - the issue from #244 is fixed because Dhall will adjust the relative path properly - but since it won't resolve the file, it's now possible to have _a single shared_ `packages.dhall`, that will contain e.g. all the packages in your repo (this wasn't possible before as you'd have circular imports in your Dhall file)
I'm rolling out Spago in a monorepo where we have multiple packages, each with their own
spago.dhall
, and a singlepackages.dhall
so that all the dependencies stay in sync.The folder structure looks like:
The
packages.dhall
contains something like:And then
package-a
listspackage-b
as a dependency in itsspago.dhall
.package-b
's path is listed as"./package-b"
and this is read by Spago and passed straight to the compiler (withsrc/**/*.purs
appended). However, because thepackages.dhall
has been moved up one level this doesn't resolve: the actual path tob
froma
should be../package-b
.I put together an SSCCE here that you can run: https://github.com/elliotdavies/spago-dependencies-example
My proposed solution would be to modify Spago so that it checks the location of
packages.dhall
and generates the correct relative path. I'm happy to do that work if you think it's a good idea!The text was updated successfully, but these errors were encountered: