Closed kowey closed 12 years ago
I can see how this would make life a little easier, but sources.txt is a file that you might share with others, and not everyone wants to use cabal-dev, particularly if they are using hsenv.
Are you trying to avo id forgetting the --dev option? What if you could have a ~/.cabal-meta file that specified it, or a proj/.cabal-meta file?
I am indeed trying to avoid forgetting the --dev. I think a global ~/.cabal-meta (perhaps with the option of a --no-dev override) would work for me.
I just pushed a commit with a new OmniConfig module. OmniConfig provides a convenient API for accepting configuration from different sources, which right now include the command line, an env variable, and a configuration file.
Unfortunately I just tested it and it doesn't seem to actually work yet :)
ok, pushed a new version master. It should pick up a --dev or --no-dev option from a config file or env variable
pushed to hackage
Hmm, might be a missing export there:
main.hs:3:8:
Could not find module `OmniConfig':
Use -v to see a list of the files searched for.
thanks, uploading cabal-meta-0.2.3.1 now
On Sun, Jul 29, 2012 at 12:24 PM, kowey reply@reply.github.com wrote:
Hmm, might be a missing export there:
main.hs:3:8: Could not find module `OmniConfig': Use -v to see a list of the files searched for.
Reply to this email directly or view it on GitHub: https://github.com/yesodweb/cabal-meta/issues/7#issuecomment-7355678
Cool, thanks! Putting a --dev
into $HOME/.cabal-meta/opts
does seem to do what I expect.
From the Institute of Advanced Mindlessness: would it be good if cabal-meta recognised a line in the sources.txt which said
--dev
? If such a line were present,cabal-meta install
would be equivalent tocabal-meta --dev install
.I guess it should only be paid attention to for the top-level package. If you provided in a sub-package but the current top-level package you're installing does not have it, the --dev in the subpackage has no effect.