How to package something that relies on haskell-emacs for melpa?

[mwotton]

sorry if this is a stupid question - do i need to do anything special to rely on haskell-emacs in a package submitted to melpa?

[knupfer]

Well, you'd declare it as a normal dependency.
Or do you want to distribute a haskell module for haskell-emacs via melpa?

[mwotton]

the difficulty as i see it is that you might need a separate stack.yaml for each project that uses haskell-emacs, as they could have different package constraints - not quite sure how this could work in the monolithic setup that's there now.

[mwotton]

i was thinking that i'd probably use stack to distribute the meat of the haskell code, with perhaps a small shim module with FromLisp/ToLisp instances.

[knupfer]

Hm, yes that is at least now a bit complicated. You'd have to instruct the user to add your dependency to his cabal and add your shim in his directory. Obviously, your melpa package could do that for the user, but that would be a bit intrusive. A good long term solution would be to allow multiple procs, so you could distribute with your melpa package a .cabal file and the rest would be automated... what do you think?

[mwotton]

this is why I tend to rely on stack more than cabal - can easily define a build with respect to a given resolver, with a couple of explicit exceptions. But yes, I tend to agree - at least packaged libraries should have their own sandbox/stack working directory/whatever nix calls it.

[knupfer]

Note that stack doesn't solve the issue here either. If you'd just append to the extra-deps you could have there mutually exclusive libs.
The core issue is that these files are managed by the user so it isn't possible to manipulate them in a safe manner (but you can obviously instruct him to depend on your lib).

[mwotton]

i was assuming you'd have different stack directories for each package using haskell-emacs? My worry is that you could have two separate libs that specify their dependencies that work apart, but can't exist in the same cabal sandbox/.stack-work.

[knupfer]

Yes, I intended to say the same. It would be ideal if every lib gets an own dir and an own process.
To accomplish that we must index some elisp variables by the directory in which is the library and give a function to register a library into haskell-emacs

[mwotton]

sounds good :)