New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

edge cases in broken templates give odd errors #1535

Closed
kadoban opened this Issue Dec 18, 2015 · 4 comments

Comments

Projects
None yet
2 participants
@kadoban
Collaborator

kadoban commented Dec 18, 2015

These are rather dumb, but I could still see them coming up in practice and it might not be the worst idea to handle them:

Blank Template

Steps to Reproduce
~$ touch blah.hsfiles
~$ stack new blah blah
Downloading template "blah" to create project "blah" in blah/ ...
/home/mud/blah/: getDirectoryContents: does not exist (No such file or directory)
Expected

An error message about the template being empty.

Template without .cabal

Steps to Reproduce
~$ printf "{-# START_FILE BOGUS #-}\n" > blah.hsfiles
~$ stack new blah blah
Downloading template "blah" to create project "blah" in blah/ ...
Writing default config file to: /home/mud/blah/stack.yaml
Basing on cabal files:

In order to init, you should have an existing .cabal file. Please try "stack new" instead
Expected

Either an inited package or (since that's probably not really sane without a .cabal file) a better error message about the template being broken. Edit: I just noticed that it works file with an empty .cabal file, so maybe it would make sense for stack.yaml to do the same thing when .cabal doesn't exist?

In particular it's kind of amusing, but not really helpful, that it tells you to run "stack new" when that's what you just tried.

If there's a real use for a template that doesn't include a .cabal file (I can't think of one, but maybe someone else can), it might be acceptable to just have a big warning about why init didn't do anything, and ideally remove the suggestion about "stack new".

Version
Version 0.1.10.1, Git revision 83ec40fc5fd6d300c73d23deb1f41d30168fc236 (2783 commits) x86_64

@mgsloan mgsloan added this to the P3: Optional milestone Dec 21, 2015

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Dec 21, 2015

Makes sense to me, seems like a good thing to fix.

@kadoban

This comment has been minimized.

Collaborator

kadoban commented Dec 21, 2015

I've got a fix for the first part (give a better error in case of a blank template) in 019dd75, I'm not entirely sure what to do about a missing .cabal file though. Options I can think of:

  1. Give an error always if there is no .cabal file.
  2. Make a --no-init option to stack new which will have it skip the init step. If initing is to be done, give an error if there is no .cabal file, otherwise maybe give a warning.
  3. Just skip the init step automatically if there is no .cabal file.
  4. "Fix" init so that it handles the case where there's no .cabal file similarly to how it handles the case where you have an empty .cabal file (it creates a stack.yaml, apparently just specifying the latest lts resolver, fine and doesn't really care that .cabal is empty).

I am not really sure what the desired outcome should be here, anyone have any thoughts? I originally thought it should just be an error, but I'm starting to wonder what it would actually hurt allowing that.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Dec 22, 2015

I'm in favor of option (1). My reasoning for each option:

(1) Seems fine, since it's unlikely that templates will intentionally lack a cabal file
(2) Let's wait until someone needs this, I don't think anyone will
(3) See reasoning for (1)
(4) "init" is useful for its handling of cabal files. People might initially misunderstand its usage if it succeeds in the absence of cabal files.

@kadoban

This comment has been minimized.

Collaborator

kadoban commented Dec 22, 2015

Sounds like good reasoning to me, thanks.

kadoban added a commit to kadoban/stack that referenced this issue Dec 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment