git dependencies should allow semver requirement

[johnslemmer]

• I have searched the issues of this repo and believe that this is not a duplicate.
• I have searched the documentation and believe that my question is not covered.

Feature Request

First thanks for creating this much needed tool for the python community.

I don't see this in the documentation or an existing issue for it, but it would be awesome if I could have a git dependency something like this:

requests = { git = "https://github.com/kennethreitz/requests.git", semver = "^2.20.0" }

That would allow for automatic updating based on the git tags that meet the semver requirement and match this regex in their tag name: ^v?\d+\.\d+\.\d+$ (or something similar).

As an example, NPM allows for this https://docs.npmjs.com/files/package.json#git-urls-as-dependencies

[dazza-codes]

Tested using a tag like tag = "^0.2" on a repository with sem-ver tags matching ^v?\d+\.\d+\.\d+$ (this repo actually has no v prefix on the versions and it has exiting 0.2.x sem-ver tags). The current poetry update does not search the tags for a matching sem-ver tag to checkout, it assumes a literal tag to checkout and fails, e.g.

$ poetry update
Updating dependencies
Resolving dependencies... (4.1s)
                                                                                                                         
[CalledProcessError]                                                                                      
Command '['git', '--git-dir', '/tmp/pypoetry-git-jupiter-log740h8tq9/.git', '--work-tree', '/tmp/pypoetry-git-jupiter-log740h8tq9', 'checkout'  
, '^0.2']' returned non-zero exit status 1.

The stack-trace points to the solver and git provider, i.e.

 /home/joe/.poetry/lib/poetry/console/commands/update.py in handle() at line 41
   return installer.run()
 /home/joe/.poetry/lib/poetry/installation/installer.py in run() at line 73
   self._do_install(local_repo)
 /home/joe/.poetry/lib/poetry/installation/installer.py in _do_install() at line 165
   ops = solver.solve(use_latest=self._whitelist)
 /home/joe/.poetry/lib/poetry/puzzle/solver.py in solve() at line 38
   packages, depths = self._solve(use_latest=use_latest)
 /home/joe/.poetry/lib/poetry/puzzle/solver.py in _solve() at line 171
   self._package, self._provider, locked=locked, use_latest=use_latest
 /home/joe/.poetry/lib/poetry/mixology/__init__.py in resolve_version() at line 7
   return solver.solve()
 /home/joe/.poetry/lib/poetry/mixology/version_solver.py in solve() at line 79
   next = self._choose_package_version()
 /home/joe/.poetry/lib/poetry/mixology/version_solver.py in _choose_package_version() at line 354
   packages = self._provider.search_for(dependency)
 /home/joe/.poetry/lib/poetry/puzzle/provider.py in search_for() at line 133
   packages = self.search_for_vcs(dependency)
 /home/joe/.poetry/lib/poetry/puzzle/provider.py in search_for_vcs() at line 175
   git.checkout(dependency.reference, tmp_dir)
 /home/joe/.poetry/lib/poetry/vcs/git.py in checkout() at line 62
   return self.run(*args)
 /home/joe/.poetry/lib/poetry/vcs/git.py in run() at line 101
   subprocess.check_output(["git"] + list(args), stderr=subprocess.STDOUT)

The solver, version_solver, provider and/or git modules need to first get all the tags from the git repository to parse all the matching sem-ver tags, sort them and solve the version matching puzzle to identify a concrete tag for git to checkout.

[dazza-codes]

PR #1176 is up for review

[dazza-codes]

@sdispater notes a veto-vote on #1176 (in it's current form) and proposes that a plugin solution (#1237) might fly. I'm considering #1176 as a WIP that could work but might impose specialized use-cases on poetry, although the implementation should only kick-in if/when the git-tag specifier is a constraint. Note that it essentially modifies one function in the git-clone-checkout workflow to select a git-tag. As a plugin, it would not constitute any new CLI commands and it's not obvious how many events could/should trigger it. If it is triggered, it's like a monkey-patch on the git-method could be invoked (but not a great idea), so it might amount to using a sub-class of the existing git-class or some form of factory for git behavior or dependency injection. At this time, I'm inclined to try to consolidate some work on #1176 into a new branch (new PR) with a git-semver subclass or alternate class, to totally isolate the option from the mainstream workflow(s). Work on any plugin for this obviously depends on plugin infrastructure (slated post 1.0) and clarification for the design for this feature as a plugin.

[stale]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[dazza-codes]

This depends on or is blocked by plugin feature(s).

[finswimmer]

Hello,

I'm not aware this is something that could be translated to PEP 508. But this is necessary to build properly wheels.

fin swimmer

[jbkoh]

Hi all, I just want to check in if it's something that poetry could potentially pursue or not. I'm heavily using github tag as a semver of my private git repo other than having a separate python package host like a private PyPI server. If poetry can support interpreting git tags as semver, it'd be a huge help.

Actually semver vs pep404 doesn't matter to me but rather I would like to use git tag to represent its version. Let me know if a solution already exists.

Thanks a lot.