Test account migration required

[deathaxe]

Package Control's CI pipeline runs integration tests against supported code hoster APIs.

Following repositories provide immutable dummy packages as test fixtures:

• BitBucket: https://bitbucket.org/wbond/package_control-tester
• GitHub: https://gitlab.com/packagecontrol-test/package_control-tester
• GitLab: https://github.com/packagecontrol-test/package_control-tester

Authentication is required to access APIs with sufficient rate limits.

Tests pick auth infos up via package_control/tests/_config.py

BitBucket and GitLab tests are executed using personal accounts, secrets of which were or are expected to be invalidated.

TODO:

Variant 1: disable automatic integration tests and rely on manual execution, locally (which anonymous rate limits may be sufficient for)

Variant 2: provide accounts and secrets to run tests with for each code hoster. Those accounts should ideally be created and owned by sublimehq.

1. modify _config.py
2. update secrets GH_PASS, GL_PASS and BB_PASS.

[michaelblyons]

Slightly offtopic: Does Codeberg need one of those repos?

[deathaxe]

Once a Codeberg client/provider would be added, probably yes - if it will.

Status of those code hoster clients/providers in Package Control is somewhat uncertain, in general. They primarily exist to drive crawler on packagecontrol.io. Being able to add git repos locally is just a side effect of crawler/client sharing same backend - be it confusing as it is.

Now that thecrawl reinvented the wheel in ways which are not re-usable client-side (without major adjustments), it means to either maintain an independent implementation for everything relevant or just drop support for adding code hoster repos directly. In that case all existing repos and tests are likely obsolete anyway.

I haven't found a satisfying answer to how to proceed. This diverged codebase topic is one of my biggest pain-points with this new infrastructure.

[FichteFoll]

Personally, I would be fine with removing the capability of adding a package by URL directly.

The vast majority of packages are installable via PC already by virtue of being registered in the default channel and those that are not are either

• private (in which case a custom channel should be provided),
• in an early dev state (and thus "not yet" added to PCC),
• or not compatible with the way PC operates.

In all these cases, a manual git clone, potentially with an explicit folder name, will get the job done just fine and it seems reasonable to expect a user to be able to do that and manage updates (git pull) by themselves for packages in any of these states.

Edit: There is actually one exception where a package not on PCC might be using PC's "dependencies.json", but as far as I am aware those can still be installed by a manual "Satisfy dependencies" invocation.

[deathaxe]

For the record: Deleted BB_PASS and GL_PASS secrets to disable related integration tests.

[michaelblyons]

Personally, I would be fine with removing the capability of adding a package by URL directly.

I would be mildly inconvenienced, but I would get over it. 😜

[deathaxe]

This is getting quite off-topic, but yeah, those code hoster providers and possible fallbacks for resolving package information in json repositories are the main reason for attempts to use asyncio and httpx2 to improve local crawling performance in case multiple git repos are configured. Without it the whole asyncio story doesn't make much sense.

ok, httpx2 is also required to get rid of tons of legacy (downloader) code, which partly relies on more or less unmaintained libraries.

Main concern remains API rate limits, especially for anonymous access.

Without all of that, we could probably even rip out support for channels and just rely on a single repository.json with resolved url-based releases, only.

It would immediately remove lots of complexity.