haskell-emacs icon indicating copy to clipboard operation
haskell-emacs copied to clipboard

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

Open mwotton opened this issue 8 years ago • 9 comments

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?

mwotton avatar Jul 04 '16 16:07 mwotton

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

knupfer avatar Jul 04 '16 17:07 knupfer

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 avatar Jul 04 '16 17:07 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.

mwotton avatar Jul 04 '16 17:07 mwotton

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?

knupfer avatar Jul 04 '16 17:07 knupfer

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.

mwotton avatar Jul 04 '16 17:07 mwotton

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).

knupfer avatar Jul 04 '16 17:07 knupfer

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.

mwotton avatar Jul 04 '16 17:07 mwotton

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

knupfer avatar Jul 04 '16 17:07 knupfer

sounds good :)

mwotton avatar Jul 04 '16 18:07 mwotton