Consider all tags pointing at a path repository's HEAD as possible versions

[drumm]

My composer.json:

{
    "name": "drumm/example-project",
    "type": "project",
    "repositories": [
        {
            "type": "path",
            "url": "../example-repo"
        }
    ],
    "require": {
        "example/repo": "^2.0"
    }
}

Output of composer diagnose:

Checking composer.json: WARNING
No license specified, it is recommended to do so. For closed-source software you may use "proprietary" as license.
Checking platform settings: OK
Checking git settings: OK
Checking http connectivity to packagist: OK
Checking https connectivity to packagist: OK
Checking github.com rate limit: OK
Checking disk free space: OK
Checking pubkeys:
Tags Public Key Fingerprint: 57815BA2 7E54DC31 7ECC7CC5 573090D0  87719BA6 8F3BB723 4E5D42D0 84A14642
Dev Public Key Fingerprint: 4AC45767 E5EC2265 2F0C1167 CBBB8A2B  0C708369 153E328C AD90147D AFE50952
OK
Checking composer version: OK
Composer version: 1.10.6
PHP version: 7.3.11
PHP binary path: /usr/bin/php
OpenSSL version: LibreSSL 2.8.3

When I run this command:

../composer.phar install -vvv --dry-run

I get the following output:

Reading ./composer.json
Loading config file ./composer.json
Checked CA file /private/etc/ssl/cert.pem: valid
Executing command (/Users/neildrumm/Downloads/test/example-project): git branch --no-color --no-abbrev -v
Executing command (/Users/neildrumm/Downloads/test/example-project): git describe --exact-match --tags
Executing command (/Users/neildrumm/Downloads/test/example-project): git log --pretty="%H" -n1 HEAD
Executing command (/Users/neildrumm/Downloads/test/example-project): hg branch
Executing command (/Users/neildrumm/Downloads/test/example-project): fossil branch list
Executing command (/Users/neildrumm/Downloads/test/example-project): fossil tag list
Executing command (/Users/neildrumm/Downloads/test/example-project): svn info --xml
Failed to initialize global composer: Composer could not find the config file: /Users/neildrumm/.composer/composer.json
To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section
Running 1.10.6 (2020-05-06 10:28:10) with PHP 7.3.11 on Darwin / 19.4.0
Loading composer repositories with package information
Executing command (/Users/neildrumm/Downloads/test/example-repo/): git log -n1 --pretty=%H
Executing command (/Users/neildrumm/Downloads/test/example-repo/): git branch --no-color --no-abbrev -v
Executing command (/Users/neildrumm/Downloads/test/example-repo/): git describe --exact-match --tags
Downloading https://repo.packagist.org/packages.json
Writing /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/packages.json into cache
Updating dependencies (including require-dev)
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2013.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2014.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2015.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2016.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2017.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2018.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2019.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2019-07.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2019-10.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2020-01.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-2020-04.json from cache
Reading /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-archived.json from cache
Downloading http://repo.packagist.org/p/provider-latest%24edd028f57858234610a9a93de3412352603082b231d2ad9052f0251ec2cb5170.json
Writing /Users/neildrumm/.composer/cache/repo/https---repo.packagist.org/p-provider-latest.json into cache
Resolving dependencies through SAT
Looking at all rules.

Dependency resolution completed in 0.000 seconds
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package example/repo ^2.0 exists as example/repo[1.0.0] but these are rejected by your constraint.

The path repository has the 2.0.0 tag checked in detached HEAD state. Both 2.0.0 and 1.0.0 tags point at the same ref:

$ git show-ref
765780e546a88ad8c0c57f6ebee2b5974323a849 refs/heads/master
765780e546a88ad8c0c57f6ebee2b5974323a849 refs/tags/1.0.0
765780e546a88ad8c0c57f6ebee2b5974323a849 refs/tags/2.0.0

And I expected this to happen:

When the require "example/repo": "^2.0" is replaced with "example/repo": "^1.0", installation succeeds. This detects the path repository's version as only 1.0.0:

Executing command (/Users/neildrumm/Downloads/test/example-project): git describe --exact-match --tags

I expect any tag pointing at the current ref to be able to fulfill the version constraint. I've attached a full archive of the project and path repository to reproduce the issue: test.tar.gz
Our use case is Drupal core packaging using local subtree splits. Some of the split components have very little commit activity, so they end up with many branches and tags pointing at the same ref, as the version number of the monorepo they are split from increases.

The workaround I came up with is to delete the other tags, so there is only one during this part of packaging

: https://bitbucket.org/drupalorg-infrastructure/subtree-splitter/src/8c5884989654af79b74acb283950af98101651b2/src/Command/CreateLockCommand.php#lines-104:111

[Seldaek]

IMO this could be done by adding a VersionGuesser::guessVersions (with s) variant, which would return all versions found, not just the first match. Then PathRepository could use that and create multiple packages for every version found. In case that helps anyone to send a PR..

As a workaround which might be easier/faster than deleting tags, you can run composer config version xxx in the example-repo dir to add "version": "xxx" to the composer.json, which should bypass the version guesser entirely.

[Seldaek]

Closing as I don't think we will ever do anything here. It's a fairly edge case scenario.