composer / satis

Simple static Composer repository generator - For a full private Composer repo use Private Packagist

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Change in PackageSelection repository filters

MaximilianKresse opened this issue · comments

The last commit broke our satis build process. This change here (from @ralflang) - to be specific: bf82c45#diff-d16a5020dc605f5cb12e0cf898bb6a7d2b2a7eacd2dc2bbc77b56b1d61d005a3L169

This version now also includes all packages from packagist in the RepositoryManager (if packagist isn't disabled in the new required composer.json).
This is probably the reason why this default repo filter was added in the first place.

The problem now is we have currently multiple external package lists like this:

{
    "repositories": [
        {
            "type": "composer",
            "url": "https://www.setasign.com/downloads/"
        }
    ]
}

Previously all packages from this repository were included in the package list. But the newly added default repo filter currently removes these.

Everything works like before if I disable packagist with a composer.json like this:

{
    "name": "satis/test",
    "type": "library",
    "require": {},
    
    "repositories": [
        {
            "packagist.org": false
        }
    ]
}

And remove the newly added default repo filter (the added else branch from L176 - L194).

This feature is an absolute MUST-HAVE for us (and probably many others too). Was this change indended and do you have any ideas to solve this? A setting to disable the default repo filter would be sufficient IMO.

Sure, I will look into why the filter does not apply anymore. This is not intended.

It does apply. But the problem is there wasn't a filter before and the newly added default filter now only include repositories which are directly added to the list of repositories. But before I used "type": "composer" to load another list without having to care which packages are inside this repository.

With this change I would have to build my satis.json configuration dynamically.

I have a hard time understanding some details. This is probably on my side.

The intended behaviour is as before:

  • no composer.json file required
  • packagist is off unless it's explicitly on

Can you please provide me the satis.json that worked until yesterday (or an anonymized version thereof)

My best guess is it's something like this:

{
    "name": "foo.com/foo-repo",
    "homepage": "https://foo.com",

    "require-all": true,
    "repositories": [
        {"name": "something/orother", "url": "https://github.com/maintaina-com/components", "type": "composer"},
        ...
    ]
}

The intended behaviour is as before:

  • no composer.json file required
  • packagist is off unless it's explicitly on

Yes!

Can you please provide me the satis.json that worked until yesterday (or an anonymized version thereof)

Your example is not so far off. Here is a small reduced example:

{
    "name": "setasign/packages",
    "homepage": "http://satis.local",
    "description": "",

    "repositories": [
        {
            "type": "composer",
            "url": "https://www.setasign.com/downloads/"
        }
    ],

    "archive": {
        "directory": "builds",
        "prefix-url": "http://satis.local",
        "whitelist": [
            "setasign/fpdi_pdf-parser",
            "setasign/setapdf-core",
            "setasign/setapdf-extractor",
            "setasign/setapdf-formfiller_full",
            "setasign/setapdf-formfiller_lite",
            "setasign/setapdf-merger",
            "setasign/setapdf-signer",
            "setasign/setapdf-stamper"
        ],
        "blacklist": [
            "setasign/*_eval_*"
        ]
    }
}

The setapdf packages are served by our own package list here: https://www.setasign.com/downloads/packages.json
This is a simple controller which list the download links for each version in the format like composer expects it.

Just as I wrote this answer and tried to collect the information I found that my description of the error isn't fully correct. The problem with the added default filter is that my repository "https://www.setasign.com/downloads/" is no package itself. It's included in $initialRepos but not in $this->repositories because $this->repositories already includes the final package. So there is never a match of $config['url'] == $satisRepo['url'].

@MaximilianKresse I found out it is never matching because of trailing slash handling. The latest commit to the PR makes me progress until I hit

elected setasign/setapdf-extractor_eval_ioncube_php7.1 (2.40.2.1773)
Selected setasign/setapdf-extractor_eval_ioncube_php7.1 (2.40.3.1782)
Selected setasign/setapdf-extractor_eval_ioncube_php8.1 (2.40.2.1773)
Selected setasign/setapdf-extractor_eval_ioncube_php8.1 (2.40.3.1782)
Creating local downloads in './out//builds'
Skipping 'setasign/setapdf-stamper_eval_ioncube_php8.1 2.40.3.1782' (is in blacklist)
Skipping 'setasign/setapdf-stamper_eval_zend_php5.3 2.4.0.723' (is in blacklist)
Skipping 'setasign/setapdf-core_eval_ioncube_php5.4 2.16.0.754' (is in blacklist)
Skipping 'setasign/setapdf-stamper_eval_ioncube_php7.1 2.32.0.1371' (is in blacklist)
Skipping 'setasign/setapdf-core_eval_ioncube_php5.3 2.13.0.699' (is in blacklist)
Skipping 'setasign/setapdf-extractor_eval_ioncube_php5.4 2.1.1.744' (is in blacklist)
Skipping 'setasign/fpdi_pdf-parser_eval_zend_php5.3 1.1.2' (is not in whitelist)
Skipping 'setasign/setapdf-merger_eval_zend_php5.2 2.6.3.768' (is in blacklist)
Skipping 'setasign/setapdf-extractor_eval_ioncube_php5.6 2.38.0.1649' (is in blacklist)
Dumping package 'setasign/setapdf-merger' in version '2.8.0.981'.
  - Downloading setasign/setapdf-merger (2.8.0.981)
Downloading https://www.setasign.com/downloads/1828406/SetaPDF-Merger_2.8.0.981-without-core.zip
[401] https://www.setasign.com/downloads/1828406/SetaPDF-Merger_2.8.0.981-without-core.zip
    Authentication required (www.setasign.com):

Later tonight I will do a bunch of tests against my own public satis repo as a source. I also need to fix some cs issues to make the linter happy.

If you feel adventurous, you can run the branch as-is - I would recommend you to wait at least until the PR leaves WIP status though.

I did not have a test case for your use case and missed how I broke this. Let's fix it :)

commented

Please let us know if the latest release (with #709) resolved this.

It looks like it's fixed now! Thank you for this fast fix!