cookiecutter.repo_name is hardcoded as app root about cookiecutter HOT 13 CLOSED

Thanks for reporting this :)

from cookiecutter.

It would be nice to get rid of the hardcoded {{ cookiecutter.repo_name }} behavior by 0.8.0, or relatively soon after if that's wishful thinking.

I'm marking this as please-help. I could really use help with this. Pull requests related to this will be given priority over others.

from cookiecutter.

As I mentioned in #153 (which is itself a duplicate of #35), one way to handle this would be to add a key/value to the cookiecutter.json file of a cookiecutter that allows the cookiecutter author to specify the root.

Something like:

{
    "__root__": "{{cookiecutter.some_other_value_than_repo_name}}/",
    //rest of cookiecutter.json content here
}

Of course you could also specify a non-templated value for __root__.

This would allow a cookiecutter author to specify a different directory as the root of their cookiecutter, and could also allow using cookiecutter to generate single files. Single-file usage would require either:

• having some logic to automagically decide whether the __root__ value is a file or a directory
  (maybe use a trailing slash?)
• or having another "magic" key (__single_file__ is suggested in #35) that specifies whether the root is a file or a directory

Thoughts? If others think this is a decent way forward, I'll start on a PR.

from cookiecutter.

Do you need magic for the single file? Couldn't cookiecutter just use os.path.isfile and isdir to determine what __root__ is and behave appropriately? You can't have a file and a directory with the same name so there is no real chance of conflict here.

from cookiecutter.

OK, so feeling dumb. :)

That was going to be my original suggestion, which I then managed to forget while writing and replace with a worse suggestion.

Using isfile/isdir certainly seems better.

from cookiecutter.

Thinking about this a bit more over the last few days, I think eventually we probably should support the following use cases:

• current case: root directory is {cookiecutter.repo_name}, this should be the default in the case where there is no value for __root__ set in the cookicutter,json file
• different templated root dir: root directory is e.g. {cookiecutter.some_other_value}
• single file with templated filename: root is a file with a name like {cookiecutte.some_vlaue}
• directory with fixed name: root directory where the name of the directory is not a template value
• single file with fixed name: root file where the name of the file is not a template value

It should go without saying that for the last two cases the content of the files is question would still be templated.

Any use cases I've missed here?

FYI, I'm mostly waiting on the completion of the contributor docs and probably the 0.8 release before I really get into this.

from cookiecutter.

I should also probably mention...

There's one other potential use case that I've been thinking about, but I'm not sure exactly how to go about it, or whether it's even a good idea to try. Should cookiecutter support the use case where the top level of the "stencil" has multiple sibling files/directories?

The only way I can think of to do this would be to add another "magic" value to cookiecutter.json, which would not include the __root__ in the output. So if you had a cookiecutter stencil that looked like this:

└───{root_dir}
    ├───{sibling_1}
    │       fiile_1.txt
    │
    └───{sibling_2}
            file_2.txt

then your output directory would look like this:

├───{sibling_1}
│       fiile_1.txt
│
└───{sibling_2}
        file_2.txt

This could be confusing though, so I'm not sure we want to get into that. Thoughts?

from cookiecutter.

Another thing, just so we're all on the same page here:

The title of this issue is misleading, as the template root is NOT currently hardcoded as
{{ cookiecutter.repo_name }}.

Instead, the current (0.7.1) behavior is to look for templated directory names (those including {{ and }}) which also have cookiecutter in them, and cookiecutter will use the first one that it finds.

So you can use {{cookiecutter.not_repo_name}} as your template root if you want, as long as cookiecutter finds it first.

See cookiecutter.find.find_template for details.

Obviously this still doesn't support all the use cases listed above, but cookiecutter does in fact support the first two (sort of), rather than just the first one, as the title of the issue might suggest.

It also means that the default behavior is not what I thought it was, so the question becomes, what should the new default behavior be?

• do what it does now, i.e. look for an appropriate template-y looking name
• do what we thought it did, i.e. look for {{cookiecutter.repo_name}}

from cookiecutter.

@khorn I have been thinking about this as well, and was planning on looking at it before I found this issue.

Some thoughts I'd had:

1. My use case was a templated setup.py all by itself, so I would want an untemplated root name and the ability for that root to be a file. You have both of those in your list of options, so that's good.
2. I was thinking that we should allow for extensibility in cookiecutter.json. Maybe leave the current format as it is, and have a new format that's a list of two dictionaries. The first would be the prompt variables as now, and the second would be a dict of template configuration. Your root would go here (no need for underscores!) and I was thinking of putting an explicit encoding in here too. There's the option to add further list elements in future iterations of the format too, if needed (maybe define hooks via config values rather than magic filenames).
3. The "multiple stencils" idea could be handled by root simply being a list rather than a single value - no need for the extra directory level.

I'm happy to help with coding, as well, if needed. And testing under Windows :-)

from cookiecutter.

@pfmoore

1. Yes, definitely.

2. See my suggestion on #30 for a more backwards-compatible option for a more complex config format. This also allows for more complex prompt logic, typed Jinja variables (that couldn't be autodetected), and maybe validation logic as well. See also #126 and #138.

   If we did change the config to look something like what I propose in #30, we could take any "configuration" data and wrap that up in a top-level object, so you might have something that looked like the following:

   {
       "__config__": {
           "root": "{my_root_template_variable}",
           "encoding": "utf-8"
       },
       "full_name": {
           "default": "Audrey Roy",
           "prompt": "Your full name?"
       },
       "email": "[email protected]",
       "repo_name": {
           "default": "boilerplate",
           "prompt": "Lowercase, spaceless, version of your repo name?",
           "help_text": "This should be a name that is importable as a Python package."
       }
   }

   This keeps the configuration stuff mostly separate, and clearly delineated from template/prompt variables, and also allows backwards compatibility with the current format (remove __config__ to get the list of prompt vars, and check whether the values of each prompt var are a simple string or an object. I really think we should avoid having two separate formats for config files, which is what you seemed to be suggesting above. Apologies if I misunderstood that.

3. I was kind of blue-skying before, but I came across a use case the other day where it would have been nice to be able to have three individual files generated from a tool like cookiecutter, so I think supporting this case makes sense. And I think allowing for a list of root templates as you suggest is a good way to go.

Thanks for the input. I really think this should be hashed out pretty thoroughly before moving forward as it's a pretty large change, and it's good to get some feedback here.

Do you have any ideas on my comments above about the current default behavior? The current situation is not terribly well defined (since it depends on the order in which cookiecutter finds things), so I'm not a huge fan of it, but I'm also leery of breaking existing code which may rely on it.

from cookiecutter.

@audreyr @pydanny Any comments on the discussion?

from cookiecutter.

👍

from cookiecutter.

Fixed long ago.

from cookiecutter.