Improve heuristics around meta.yaml source path and git_url

[kwmsmith]

We hit a subtle issue when defining:

source:
   path: ../

when we should have set:

source:
   git_url: ../

This shows up as an empty version string in any jinja templates, and is somewhat subtle to debug.

Because conda decides to set git related env vars based on the presence of source/git_url, these vars weren't set for the jinja templates, leading to an empty version string.

Possible solutions:

• deprecate the source/path key
• something else?

[groutr]

Question to the community: Are there any compelling use cases for source/path that aren't already handled by source/git_url (or equivalent key)?

[msarahan]

I think we're stuck between a rock and a hard place. A user complained that a recipe was not building because conda build was looking for git, but git was not installed. This was on windows. Conda build was looking for git because a .git folder was present, and the path heuristic found that, and triggered the git logic. We (Ilan) thus removed it.

I see the path entry as perhaps needing documentation regarding not defining git stuff for jinja2, but also needing to be kept. git_url should be used if you want git to do stuff like provide version info.

[stuarteberg]

This shows up as an empty version string in any jinja templates, and is somewhat subtle to debug.

Was that behavior observed using the latest version of the master branch, or using conda-build 1.19.0?

I think the behavior here has been slightly improved in the master branch. Instead of simply seeing an empty string for GIT_DESCRIBE_TAG, which is subtle to debug, you will now see an error message like Error: 'GIT_DESCRIBE_TAG' is undefined. Hopefully a complaint about a GIT_ variable will nudge users towards providing git_url instead of path.

[stuarteberg]

Question to the community: Are there any compelling use cases for source/path that aren't already handled by source/git_url (or equivalent key)?

The source/path case allows you to avoid re-cloning the repo. I don't think that's a huge deal, but apparently at least some users are hurting from the additional overhead. See #753.

[stuarteberg]

The source/path case allows you to avoid re-cloning the repo.

I now see that the source/git_depth setting in meta.yaml can alleviate this concern, at least in part. (It had a tiny bug, though. See #803 for a tiny fix.)

[groutr]

The only practical difference between source/git_url and source/path should now be that git_url is a clone of a repository and path is copy of the repository. Using path will allow you to build packages with unstaged/uncommited changes in working directory. git_url will only build up to/including the latest commit.

[github-actions]

Hi there, thank you for your contribution!

This issue has been automatically locked because it has not had recent activity after being closed.

Please open a new issue if needed.

Thanks!