On Friday, July 11, 2014 2:08:13 AM UTC+12, ShanaTsunTsunLove wrote: > > 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. >
Yeah, this was my understanding, too. I figure having a config package/project and having a local dependency are more/less the same thing. I was playing around with it a bit, It is possible to get a yi.hs as minimal as like "import Yi.Config.Rgoulter", if your main is in module Yi.Config.Rgoulter, in some cabal project added to the ~/programming/yi/yi sandbox through 'add source'. An advantage of this approach is if there're multiple local dependencies, then Yi.Config.Rgoulter will depend on these, and so any changes can be updated with like "cabal install yi-config-rgoulter". (See below). I guess a cabalised config like this could also ensure dependent packages a config might have. A disadvantage is that a token change needs to also be made to yi.hs for Yi to recognise it needs to recompile its configuration, otherwise it won't take into account any updated local dependencies. (Well, "touch yi.hs" is enough to recognise Yi.hs has changed). I guess this is true regardless of whether a sandbox is used for Yi or not. > * 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. > You're correct about "cabal sandbox add-source ~/foo/bar" not needing ~/foo/bar to be in a sandbox. (My concern was, if ~/foo/bar depends on some change in ~/programming/yi/yi, then ~/foo/bar would need to be built. This isn't the case). > > > > 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. > I'm not sure if this is just me being dumb, (or ignorantly pedantic), but for me "cabal sandbox add-source ~/mydepproject" wasn't enough, I also had to have "cabal install mydepproject". And since I did need to "cabal install mydepproject", then I suppose I should also say I needed to call this command again if I did modify ~/mydepproject. If this isn't supposed to be the case, I'm not quite sure what's up. Regards, Richard -- -- 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.
