Skip to content
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

InvalidRelFile when using stack solver #1954

Closed
maxigit opened this issue Mar 26, 2016 · 9 comments
Closed

InvalidRelFile when using stack solver #1954

maxigit opened this issue Mar 26, 2016 · 9 comments

Comments

@maxigit
Copy link

maxigit commented Mar 26, 2016

Following this question I concluded it is a bug. I'll just copy paste my question and own answer from SO.

tl;dr

Using ../my_package using stack solver throw a InvalidRelFile exception where as stack build works fine. I'm happy to provide links to the broken package to help reproducing the bug if needed.

Original question

I'm having this strange issue : I'm trying to add a local package to my stack file and I get the following error. when I try to build it (stack build) it kind of work but fails suggesting me to use stack solver but when I run stack solver I got the following error

Using configuration file: stack.yaml
InvalidRelFile "/home/max/devel/sql-fragment/sql-fragment.cabal"

My stack file looks like

flags: {}
packages:

  • '.'
  • ../sql-fragment
    extra-deps:
    ...

I'm on Ubuntu 15.02 trying to use GHC-7.8.4 and stack 1.0.4 The two packages, sql-fragment and sql-fragment-mysql-simple can be found on github.

Answer

It's probably a bug in stack. I managed to find a workaround by moving sql-fragment directory into sql-fragment-mysql-simple, change ../sql-fragment to sql-fragment in the stack file launch the solver -stack solver --update-config and it works. What is strange is, I add to properly move the directory to make it work (just creating a symbolic link woudn't work) and once the solver has done its job. I moved sql-fragment where it was, revert the path to ../sql-fragment andstack build` works perfectly ;-)

@harendra-kumar
Copy link
Collaborator

I am not sure if there are any issues in allowing packages outside the current directory. Though nothing stops us from doing that and we can support that use case, it might be simpler to think of stack.yaml only covering packages under the dir tree. Anything outside the tree can be treated as external package with something like this:

packages:
- location: ../sql-fragment
  extra-dep: true

@mgsloan any thoughts on supporting outside the tree packages as part of the project? Anyway, we will have to either fix this or provide an appropriate error message.

I think the technical issue here is that when we try to make a path relative to the current directory using makeRelativeToCurrentDir it in turn uses makeRelative on the path which will not make the path relative unless it is under the current directory and therefore a subsequent parseRelFile will fail on that path.

@maxigit
Copy link
Author

maxigit commented Mar 27, 2016

As I said, the problem only appears with stack solver, stack build works fine. Also trying to give a absolute path ( which doesn't make sense either) returns the same error.

@mgsloan mgsloan added this to the P2: Should milestone Mar 28, 2016
@mgsloan
Copy link
Contributor

mgsloan commented Mar 28, 2016

I think the implementation of makeRelative should change - mrkkrp/path-io#10

@mrkkrp
Copy link
Collaborator

mrkkrp commented Apr 6, 2016

@mgsloan, I've answered in mrkkrp/path-io#10 that it's not currently possible to construct Paths with .. in them (because of smart constructors), even if makeRelative from directory could create paths with .. in them. Is there anything I can do to help?

@maxigit
Copy link
Author

maxigit commented Apr 7, 2016

@mrkkrp we can debate if .. should be accepted or not, but the behavior should be consistent. stack build accepts .. but stack solve doesn't, why ? Is stack build not using makeRelative.

My argument in favor of .. is, how do you work with local packages ? The way I do is to have a Haskell directory under my home directory. Let's say I have a package A and B which depend on A, I naturaly use ../B. I understand it's not portable but nothing is. ~/Haskell/B is not better. Using an absolute path is even worth, so what can I do ?

@mgsloan
Copy link
Contributor

mgsloan commented Apr 7, 2016

Yeah, stack solver should just use whatever stack build is using.

It makes sense for path not to assume the existence of ... However, it would be nice to have some utilities similar to makeRelative which yield paths that use .. (and probably checking for their existence), perhaps not yielding a Path but some other type.

@dbc60
Copy link

dbc60 commented Apr 18, 2016

FYI, I'm trying out stack for the first time on Windows 10. I ran into this issue while following the instructions on New in-depth guide to stack. It said to run stack build cabal-install followed by stack solver. It was missing stack install cabal-install, so without cabal.exe in my path I got:

P:\> stack solver
Run from outside a project, using implicit global project config
Using resolver: lts-5.13 from implicit global project's config file: E:\StackRoot\global-project\stack.yaml
InvalidRelFile "E:\\StackRoot\\global-project\\stack.yaml"

Interestingly, running stack init --resolver lts-5.13 --solver resulted in a much more informative message:

P:\> stack init --resolver lts-5.13 --solver
Using cabal packages:
- yackage.cabal

Selected resolver: lts-5.13
*** Resolver lts-5.13 will need external packages:
    acme-missiles not found
        - yackage requires -any
    Using package flags:
        - yackage: upload = True

Using resolver: lts-5.13
Solver requires that cabal be on your PATH
Try running 'stack install cabal-install'

After running stack install cabal-install I could run stack solver with no errors, and I suspect I'd get identical results with stack init --solver.

@mgsloan
Copy link
Contributor

mgsloan commented Apr 29, 2016

I am fixing this by just not using makeRelative

@mgsloan
Copy link
Contributor

mgsloan commented Apr 29, 2016

Turns out it was just making files relative for display. Fix is just to display absolute paths for things above the current dir.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants