How to install a global library with stack?

[Marcos Pividori]

Hi everyone,

I am working on a project developing Haskell bindings for OpenCog, an open source framework for Artificial General Intelligence. I am currently developing a haskell library that uses FFI to communicate with the existing framework.

After working with cabal-install for the building and installation, as I expected it would happen, some users had problems using different ghc versions/package databases states, etc, that I didn't manage to reproduce. So, looking for a solution to this, I ran into Stack! Great! I plan to start using it.

I am building the library in some specific location. But I want the user to be able to import and build executables using this library anywhere in the filesystem. Can I install it globally? as with cabal-install default?

I couldn't find an answer to this in the documentation. I noticed that there is a default stack global dir in ~/.stack/global .... How do I install a library there by command line? Should I manually modify the global stack.yaml file to include my project directory?

How would be the proper workaround this? I know I can set STACK_YAML to use an environment from a different directory. But I would prefer to install the library globally.

I think this is similar to what David Virebayre mentioned on last email: " - tried to find a way for stack install to install globally. Didn't search too long though. "

Thanks!

Marcos

[Michael Snoyman]

On my phone now so I can't go into deep detail. But the best route is to tell users to add your library to the packages list in their stack.yaml file. A simple explanation is that you have no way of knowing in advance which GHC version or library versions they'll want to build against.

--
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/283169e5-74a2-47f2-a32f-b4eebb9b0332%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marcos Pividori]

Hi Michael,

Thanks for your response! Ok. So, if I understand properly, for example, in order to build a simple executable that uses the library, users have 2 options:

  - They could manually specify the location of the library with:
     stack ghc example.hs --stack-yaml=....yaml file of the library project....
     (or previously define the STACK_YAML variable)

  - Or, they could add the library path to their package list in their local config file: ~/.stack/global/stack.yaml
    Execute: stack install libname
    And then just use: stack ghc example.hs

Am I understanding correctly?

Thanks!

Marcos

El domingo, 12 de julio de 2015, 4:26:32 (UTC-3), Michael Snoyman escribió:

On my phone now so I can't go into deep detail. But the best route is to tell users to add your library to the packages list in their stack.yaml file. A simple explanation is that you have no way of knowing in advance which GHC version or library versions they'll want to build against.

[Michael Snoyman]

Ah, I see, you're targeting the case where the user has a .hs file, not a complete .cabal project. Yes, you've got it nailed :)

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/ddddf353-6d08-4fe9-ba8e-57648101ab91%40googlegroups.com.

[Marcos Pividori]

Hi,

Here I am again! As I mentioned before I am working on a project developing Haskell bindings for OpenCog, an open source framework for Artificial General Intelligence.

Every software of the OpenCog framework is installed on /usr/local/...

So, I would like to locate haskell bindings there, for example on: /usr/local/lib/opencog/haskell... not on user space such as ~/.stack/.....

So everyone that wants to use this bindings just add the library path to their package list in their stack.yaml config file.

But what I can not understand is why, when I use the library somewhere, it also attempts to create a .stack-work folder in the location of the library?? It is a problem because they need root privileges to create the /usr/local/lib/opencog/haskell/.stack-work dir, etc.

How can I locate a read only haskell library in some privileged dir that can be used by every user??

Thanks,

Marcos

El lunes, 13 de julio de 2015, 2:03:30 (UTC-3), Michael Snoyman escribió:

Ah, I see, you're targeting the case where the user has a .hs file, not a complete .cabal project. Yes, you've got it nailed :)

[Michael Snoyman]

I can't speak for others, but personally I don't understand your goals here, or what steps you're following to get these results.

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/84f6d02d-67c5-45cc-844e-27d7a5b25e19%40googlegroups.com.

[Marcos Pividori]

Hi Michael,
Thanks for your response.
I mean. I have a package "opencog-atomspace", a haskell library. If I move it to: /usr/local/lib/opencog/opencog-atomspace
Then, when I need to use that package somewhere, I include its path to my stack.yaml file, like:
    ...
    packages:

     - '/usr/local/lib/opencog/opencog-atomspace'
    ...

Then, I was expecting that, when using stack, it would build a copy of that package in its own .stack-work folder. But it also tries to write some information to the '/usr/local/lib/opencog/opencog-atomspace' directory and that is the problem.

Probably I am not properly understanding how stack works behind.
Thanks for your time!

Marcos

El viernes, 17 de julio de 2015, 12:07:02 (UTC-3), Michael Snoyman escribió:

I can't speak for others, but personally I don't understand your goals here, or what steps you're following to get these results.

[Michael Snoyman]

The original way we designed stack would have allowed this, but we ran into a bug on windows with absolute paths so stuck with relative paths.

If you generate a tarball and reference that instead, it should provide the behavior you're looking for by decompressing in a user directory.

[Mathieu Boespflug]

Hi Marcos,

is installing the source files to your library in a global location a hard requirement? Why don't you stick your library in a git repository somewhere, or behind an HTTP server, and have users put either

packages:

- git: github.com/foo/bar

  commit: ...

or

packages:

- https://www.example.com/foo-0.1.tar.gz

That way, you can roll out upgrades to your library very easily. See https://github.com/commercialhaskell/stack/wiki/stack.yaml

Best,

Mathieu

[Marcos Pividori]

Hi,
Yes. I was thinking of that.

Unfortunately it looks like there is a bug: stack only accepts ".tar.gz"  files to be downloaded from some url, not on local file system path.

When adding: "/usr/local/lib/opencog/haskell/opencog-atomspace.tar.gz" to the package list in the stack.yaml file:

    Could not resolve directory /usr/local/share/opencog/haskell/opencog-atomspace-0.1.0.0.tar.gz

Stacks considers it as a directory. I will add an issue for this.

Thanks,

Marcos

[Michael Snoyman]

Supporting file:// URLs seems like an easy extension to what we're already doing, and fits in with the work I did for custom snapshots

To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/CAOPS0rp65qQWeWD%2Bu%2B3PrNXGVAdrLXdDRyaWe_ZBYg%3D1RFYNVQ%40mail.gmail.com.