projectatomic
Feature request: add -a parameter to genanswers
If I do:
atomicapp genanswers atomic-site/Nulecule
It will drop an answers.conf.sample in my current directory, not in the target directory of atomic-site/Nulecule. Which is both messy, and a problem because 'atomicapp run' will look for answers.conf in the target directory when it runs.
Well it depends on your take on this. Most of the time genanswers is used is when you want to grab answers from a remote docker image, modify them, and then run the app like so:
atomicapp genanswers projectatomic/helloapache
vi answers.conf
atomicapp run projectatomic/helloapache -a answers.conf
In this case what you are saying is atomicapp genanswers atomic-site/Nulecule where atomic-site/Nulecule is a directory that already exists?
With genanswers, up until this point, there has been no concept of a target directory.
What I'm talking about is sensible defaults. That is, the default for one command should be the same as the default for another command. If genanswers drops answers.conf in the current directory, then run should look in the current directory first, without requiring a parameter from the user.
Having the default be one thing for genanswers and something different for run is very unfriendly, and makes it harder to learn the tool.
I'll be honest I've never used genanswers in a context where I wasn't grabbing it from a remote image. So there are two cases:
- generating from nulecule that is embedded in docker image
- generating from local nulecule
For 1. is it ok to have it populated in the local directory. I don't really see another option without forcing the user to tell us where to put it.
For 2. we can detect this and put it in the directory given (my thoughts are that most of the time the user would be in the directory and just pass ./).
The only problem with the above approach is that it's inconsistent based on where the nulecule currently resides, which I don't like.
well, per above, my concern is that run and genanswers should have the same behavior. So if it's going to make sense in a lot of cases to drop it in the current directory, then run should also look in the current directory for answers by default.
I definitely don't think having run look in the local dir is a solution so let's search elsewhere.
genanswers is the only case that exists where there won't be a context directory (i.e. a local directory where a nulecule is extracted to) that results from an action. In the case of fetch, which is almost the same as genanswers but actually does leave a directory on the local system, the sample answers file gets put in the context directory.
since genanswers is a bit special in that regard, we treated it a bit differently.. the idea is that if you are running genanswers you are basically asking for something very specific; generate an answers file and put it in my cwd.
I guess we could generate a message to the user to tell them exactly where we put the answers.conf file. Maybe that would make it a bit more clear.
I guess I'm not seeing what's wrong with putting it in the Nulecule directory if the user supplies one? If the user wants it somewhere else, then they could supply a -a.
-1 on the message.
I just personally like consistent behavior. For this command, since there will not always be a local context dir I would prefer that it always just populates in cwd.
If the user wants to use a Nulecule from a local dir then they could cd to the directory first:
cd atomic-site/Nulecule
atomicapp genanswers .
The only way to have consistent behavior with this command is to leave it this way, or force the user to specify where he wants it to be output everytime (i.e. don't assume where they want it).
The only way to have consistent behavior with this command is to leave it this way, or force the user to specify where he wants it to be output everytime (i.e. don't assume where they want it).
@jberkus did the previous discussion give any resolution to this issue in your mind?
Changed issue. Now it's a feature request: we should support "-a" for genanswers so that I can designate where to put the answers.conf through some mechanism other than "cd".
