--work-dir and relative paths

[Magnus Therning]

I was rather excited to read about the addition of `--work-dir`. Even
with the limitation of only accepting relative paths. However, it turns
out that /path/[1] has a very different idea about relative paths than I
do. So now my excitement about `--work-dir` is completely gone :-(

I'd argue that both of the following paths are relative:

./workdir
../workdir

according to /path/ however, only the former is and not the latter!

I've reported this as a bug[2], but I'm also wondering if someone's
working on allowing absolute paths to the work dir?

/M

[1]: http://hackage.haskell.org/package/path
[2]: https://github.com/chrisdone/path/pull/8

--
Magnus Therning OpenPGP: 0x927912051716CE39
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus

Programs should be written for people to read, and only incidentally
for machines to execute.
-- Quote from Structure and Interpretation of Computer Programs

[Emanuel Borsboom]

I'm hesitant to add support for parent directories for the .stack-work directories, since there is one for every package and by specifying `../.stack-work` it means they could end up overlapping each other.  We'd actually prefer to only need a single `.stack-work` for the whole project, but that causes problems on Windows.

Can you tell us a bit more about your use case?  In general, putting project-related stuff like `.stack-work` outside of the project directory is probably not a good idea, but maybe you have a use case we haven't thought of (or maybe we can recommend a different approach to reach the same goal).

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stac...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/87poxdxz47.fsf%40sobel.cipherstone.com.
For more options, visit https://groups.google.com/d/optout.

[Magnus Therning]

Emanuel Borsboom writes:

> I'm hesitant to add support for parent directories for the .stack-work
> directories, since there is one for every package and by specifying
> `../.stack-work` it means they could end up overlapping each other.
> We'd actually prefer to only need a single `.stack-work` for the whole
> project, but that causes problems on Windows.
>
> Can you tell us a bit more about your use case? In general, putting
> project-related stuff like `.stack-work` outside of the project
> directory is probably not a good idea, but maybe you have a use case
> we haven't thought of (or maybe we can recommend a different approach
> to reach the same goal).

I'm working on a C/C++ project that uses CMake to build. The
recommended practice is to build "out of place" (i.e. so that build
artifacts don't mix with the source. Since I've joined the project I've
been writing a few tools in Haskell which are built using stack and
hooked in via CMake's ExternalProject module[1]. So to make stack mix
well with the rest of the project I'd like to direct it to use a work
dir that isn't a sub-folder of the source dir.

/M

[1]: https://cmake.org/cmake/help/v3.2/module/ExternalProject.html

--
Magnus Therning OpenPGP: 0x927912051716CE39
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus

We act as though comfort and luxury were the chief requirements of
life, when all that we need to make us happy is something to be
enthusiastic about.
-- Albert Einstein

[Emanuel Borsboom]

I think it makes sense to accommodate this type of use case. The first step would be to add support for consolidating all packages’ .stack-works into a single one for the project. Way in the past, this was actually how Stack always did it, so adding that back shouldn’t be too difficult. I’d actually prefer that it were the standard behaviour. Once that’s done, we can make --work-dir accept absolute paths and relative paths containing ...

However, there's a wrinkle: there’s a Cabal issue that causes problems if the dist directory is not within the package’s directory on Windows. We haven’t put a lot of effort into finding a workaround, so it may be possible to find a way around this or fix it upstream. If not, we’d have to fall back to the current behaviour on Windows and would not be able to support to support a .work-dir outside the project/package on that platform. But I think some effort should be put into determining and fixing the root cause, if possible.

Can you document this in a Github issue so we don’t lose track of it? And would you be interested in working on a pull request to implement it?

[Arnaud Bailly | Capital Match]

Thanks a lot, that would be a great improvement for us here at Capital Match !

Is there a way we could help?

Regards,

--

You received this message because you are subscribed to the Google Groups "haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stac...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/CACGj5vJe7c4_X6VT7rQF1gZ4Jj7R2yB0mwajTihFKzJ%3DB%3DF04A%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Arnaud Bailly
CTO | Capital Match

CapitalMatch

39A ​North Canal Road | Singapore ​059295

+33 617 121 978 | arn...@capital-match.com | www.capital-match.com

Capital Match Platform Pte. Ltd., registered in Singapore (Co. Reg. No. 201501788H), is a subsidiary of Capital Match Holdings Pte. Ltd. (Co. Reg. No. 201418682W) (collectively "Capital Match").

This e-mail message and any enclosures are intended only for the person(s) to whom it is addressed and may contain information which is confidential and/or legally protected. Any use, distribution, modification, copying or disclosure by any person(s) other than the named addressee is strictly prohibited. Capital Match disclaims all responsibility from and accept no liability whatsoever for the consequences of any unauthorized person acting, or refraining from acting, on any information contained in this message. If you have received this email in error, please inform us immediately and delete it and all copies from your system.

E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive later or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required, please request a hard-copy version from the sender. Capital Match makes no representation or warranty as to the absence of viruses in this e-mail or any attachments.

[Magnus Therning]

Emanuel Borsboom writes:

> I think it makes sense to accommodate this type of use case. The first step
> would be to add support for consolidating all packages’ .stack-works into a
> single one for the project. Way in the past, this was actually how Stack
> always did it, so adding that back shouldn’t be too difficult. I’d actually
> prefer that it were the standard behaviour. Once that’s done, we can make
> --work-dir accept absolute paths and relative paths containing ...
>
> However, there's a wrinkle: there’s a Cabal issue that causes problems if
> the dist directory is not within the package’s directory on Windows. We
> haven’t put a lot of effort into finding a workaround, so it may be
> possible to find a way around this or fix it upstream. If not, we’d have to
> fall back to the current behaviour on Windows and would not be able to
> support to support a .work-dir outside the project/package on that
> platform. But I think some effort should be put into determining and fixing
> the root cause, if possible.
>
> Can you document this in a Github issue so we don’t lose track of it? And
> would you be interested in working on a pull request to implement it?

Since I'm so slow someone else beat me to it :)

https://github.com/commercialhaskell/stack/issues/1731

I can also add that I made a naive attempt at simply change the type

#+BEGIN_SRC haskell
data Config =
...
,configWorkDir :: !(Path Abs Dir)
...
#+END_SRC

and then continued to just work out the type errors that caused. I started with
resolving it using ~resolveDir'~ (from ~Path.IO~) and continued from there with
one type error at a time. After a while I ran into the mixed use of relative and
absolute dirs in the source. In short, I gave up after getting the feeling that
I really would need a better understanding of how the dirs all fit together
before making this change.

/M

--
Magnus Therning OpenPGP: 0x927912051716CE39
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus

Where the people fear the government you have tyranny. Where the
government fears the people you have liberty.
-- John Basil Barnhill

[Mark Fine]

I ran into this issue with a project that built stack applications in a temporary location - the project needed the ability to build relocate the .stack-work directory outside an application's directory hierarchy. I ended up having to move directories back and forth to workaround the problem.

I went through an exercise of converting work-dir from a relative path to an either absolute or relative path:

 -- | The top-level Stackage configuration.

 data Config =

   Config {configStackRoot           :: !(Path Abs Dir)

          -- ^ ~/.stack more often than not

-         ,configWorkDir             :: !(Path Rel Dir)

+         ,configWorkDir             :: !(Either (Path Abs Dir) (Path Rel Dir))

          -- ^ this allows to override .stack-work directory

and threading it throughout stack:

https://github.com/commercialhaskell/stack/issues/1731#issuecomment-243680114

https://github.com/commercialhaskell/stack/compare/master...mfine:mfine-abs-rel-work-dir

The changes are pretty woof, but to be able to get the .stack-work directory relocated like this was awesome:

$ repos/hellos > ~/.local/bin/stack build --work-dir /Users/mark/tmp/stack-work

Populated index cache.

Did not find .cabal file for stm-containers-0.2.11 with Git SHA of 9410bc0f41fe0b458f7c350ce4a5a17cdbe3f18e

Did not find .cabal file for kansas-comet-0.4 with Git SHA of be4690cfa4a780f71d05182fe5c69bb4ae635bf7

Did not find .cabal file for hledger-lib-0.27 with Git SHA of 9ad40bc0d38fb9fa2a96e2f5211fef8e2b405222

Did not find .cabal file for blank-canvas-0.6 with Git SHA of 1ab8537279ad2dd4cf25f76527633d47e5b16a94

hellos-0.0.0: configure

Configuring hellos-0.0.0...

hellos-0.0.0: build

Preprocessing executable 'hellos' for hellos-0.0.0...

[1 of 1] Compiling Main             ( Main.hs, /Users/mark/tmp/stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/hellos/hellos-tmp/Main.o )

Linking /Users/mark/tmp/stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/hellos/hellos ...

hellos-0.0.0: copy/register

Installing executable(s) in

/Users/mark/tmp/stack-work/install/x86_64-osx/lts-5.18/7.10.3/bin

$ repos/hellos > ~/.local/bin/stack exec hellos --work-dir /Users/mark/tmp/stack-work

Setting phasers to stun... (port 3000) (ctrl-c to quit)

"CurrentDirectory /Users/mark/tmp/stack-work/install/x86_64-osx/lts-5.18/7.10.3/share/x86_64-osx-ghc-7.10.3/hello-0.0.0"

"DataDir /Users/mark/repos/hellos"

Would love to see this make it into stack and would be willing to contribute towards it!

Mark

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.

To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stack+unsubscribe@googlegroups.com.

To post to this group, send email to haskel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/874mdk41vm.fsf%40therning.org.