Feature request: disable the subdirectory warning

[wosc]

In one project we have a "monorepo" setup that looks like this:

/myrepo
  .git/
  package1/
    setup.py
  package2/
    setup.py

Happily, zest.releaser completely does the right thing for cd package1; fullrelease, i.e. the egg is correctly created from the package1 subdirectory and everything. :)

There's just one little niggle, namely the first thing it asks you is "do you want to go to the root of the repository?". Which in this case, no we definitely do not. ;) Do you think that could be supported? I'm not really sure what the appropriate gesture could be, presence of setup.py or setup.cfg or an explicit marker file or something else entirely.

[mauritsvanrees]

Seems reasonable, and I guess looking for a setup.py would be okay. But it can get tricky. Say you are in /myrepo/package1/subdir and you do fullrelease.

• The current directory has no setup.py file and no .git directory, so it is definitely the wrong directory. Fine.
• So we should go one level up, where we find setup.py but no .git.
• One more and we have .git but no setup.py.

In this case it should take /myrepo/.git/ as the repository root, but it should offer to change the directory from /myrepo/package1/subdir/ to /myrepo/package1/.

And then we have a different scenario that I often have, with the same directory structure as you have: one repository for a website, which contains some (buildout) configuration in the top directory and several packages. I don't make individual releases for the packages, but I want a single release for the whole website. So when I am in /myrepo/package1/subdir and do fullrelease, I definitely do want to go to the top level directory.

Now, in my case I always make sure to be in the top level directory when I call fullrelease, but the use case is valid. I can imagine that I am in the /myrepo/package1 directory, do fullrelease, and am happy that zest.releaser reminds me that I am not in the repository root: "Yes please, take me to the root, thank you for reminding me." :-)

So the thing is that the version_control function does two things:

1. Find the .git directory.
2. Possibly change the directory to where a setup.py file is or where the .git directory is, which may or may not be the same directory.

What we could do, is change the default answer to "no" when the current directory has a setup.py.

But when we do this properly, we may need to ask not one, but two questions:

1. "There is a setup.py file one level up, do you want to go there? (Y/n)"
2. "Do you want to go to the root of the repository? (Y/n)"

And then the question is: if the user answers 1 with "yes", do we then still ask the second question? And would it change the default for the second question? And if the user answers 1 with "no", do we then still ask the second question? And would it change the default for the second question? [Edit: and would it maybe make more sense to first ask the second question and then the first?]

In other words: this gets pretty hairy. :-(

Like I said, we could change the default answer to the current question to "no", either always or conditionally when there is a setup.py. But we would still be asking the question. I am not sure if you would consider that an improvement.

[wosc]

I was smelling some of these complications when I wrote this, but not in this much glorious detail. Thanks for taking the time to go through this!

And yes, I'd consider it a definite improvement if the default answer for "go to the root" could be changed to "no" -- because that would bring (at least) our use case in line again with how we usually can work fullrelease: "in 99% of the cases, just accept the defaults and you'll be fine".

Should I prepare a patch to change the default to no if a setup.py is found? Or do you want to take a policy decision and always set it to no?

[mauritsvanrees]

@reinout Would you mind if we change the default answer for "do you want to go to the root of the repository" to No? I'd say such a change is okay.

[reinout]

Fine with me. I assume there's going to be a good changelog entry :-)

[mauritsvanrees]

Closed in PR #328. I have released 6.19.0 with this.

[wosc]

Thank you! :)