On 07/10/2014 06:26 AM, Richard Goulter wrote: > Hi, > > I'm wondering what the easiest way is to "split up" a ~/.config/yi/yi.hs > file into multiple .hs files. > (Alas, just putting other .hs files into ~/.config/yi/ didn't work..).
I have wondered how to do this before. I think I saw it done but I have only a vague memory of it. The easiest way I can think of would be to make the rest of your files into a project and import that from your config. Your config is the ‘Main’ module, it is what gets compiled to ~/.cache/yi and ran. > Particularly, if I'm running Yi from a sandbox. The GitHub readme for Yi > says: > > If the package your config depends on is local, for example when you're > developing the library that you want to use or if you need a patched > version, you'll have to use cabal sandbox add-source command. As an > example, I'm developing a yi-haskell-utils package and my config depends on > it. To accommodate for this, I rancabal sandbox add-source > ~/programming/yi-haskell-utils. > > but I wasn't able to get this working with any success. When I run Yi while > importing a module from (say) yi-haskell-utils, Yi isn't able to find the > module. > Is there much obvious which is missing from the instructions? > > If I have a cabal sandbox for Yi at (say) ~/programming/yi/yi,... > * yi-haskell-utils is going to depend on yi. Can yi-haskell-utils > add-source for ~/programming/yi/yi, or is that cyclic? I had success doing so before. > * in order for Yi to know about yi-haskell-utils used in yi.hs, would I > have to tinker with yi.cabal in ~/programming/yi/yi at all? No. Once Yi itself is compiled, cabal goes out of the window. The only reason we use sandboxes to add packages on which your config depends on is that they are built and accessible under .cabal-sandbox/… . You should never have to touch yi.cabal. You should use either add-source or cabal install depname and GHC_PACKAGE_PATH should handle the rest. > * would ~/programming/yi-haskell-utils need to be in a cabal sandbox, or > need to not be, and if it's in a sandbox can it share the same sandbox as > ~/programming/yi/yi or not? I don't know if it has to be, I don't remember what cabal dictates. As long as you can add-source it, you should be good. I'm unsure what you mean by sharing a sandbox. > * would I need to tinker with the GHC_PACKAGE_PATH in my runyi script? Possibly. I'd advise that you add a print to see what it actually is and ensure a path to the packages of your choices is passed properly. It should be a colon-separated (something else on Windows IIRC) list of paths to each of the dependencies available to Yi at compile of your config and then effectively at runtime. You can find few words about the variable in the GHC manual. > > > I'd appreciate any information to clarify things like this. > Regards, > Richard > Basically, I think the setup should be something like this: programming/yi/yi – sandbox programming/mydepproject – also a sandbox but I'm unsure if necessary, I was doing dev here so I used one ~/.config/yi – I seem to have sandbox files here but it seems like they are unrelated then in programming/yi/yi add-source programming/mydepproject and all other local dependencies: if you're using extra deps from Hackage, just run ‘cabal install depname’ inside the Yi sandbox; programming/mydepproject add-source programming/yi/yi I hope this clears up some things for you. I no longer use cabal sandboxes so I can't immediately try it all out. Please report back and/or feel free to send corrections/improvements to README or else on GitHub. -- Mateusz K. -- -- Yi development mailing list yi-devel@googlegroups.com http://groups.google.com/group/yi-devel --- You received this message because you are subscribed to the Google Groups "yi.devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to yi-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
