Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

testing dependencies in 3.8 #276

Open
rchl opened this issue Oct 19, 2024 · 4 comments
Open

testing dependencies in 3.8 #276

rchl opened this issue Oct 19, 2024 · 4 comments

Comments

@rchl
Copy link
Member

rchl commented Oct 19, 2024

I've been using this action to test lsp_utils dependency in:

https://github.com/sublimelsp/lsp_utils/blob/f2a43fa2db4aeddbcf8ea1ce79ce95f143ddc696/.github/workflows/on-pull-request.yml#L18-L38

With PC 4 now it's no longer enough to link dependency in Packages/*. Now it needs to be linked in ../Lib/python38/*. And not the root directory of the dependency itself has to be linked but rather the dependency_name/st3/dependency_name/ instead.
And the tests I guess still have to be copied/linked to Packages/* with according .python-version added.

I suppose it's a bit of a tricky case to handle now but this is the issue asking for adding support for that. :)

@deathaxe
Copy link
Member

I see the pain.

However, UnitTesting installs required (extra-)packages and their dependencies via Package Control and thus has no idea of old depencendy format vs. new libraries, nor their storage location. It also treat alls folders in Packages directory as normal packages.

As a result specified LSP-pyright extra-package causes latest release of lsp_utils library being installed to lib/python38 already. Hence it is not possible to "just link" any folder from a checked out repo to lib/python38 even if it would be within scope of UnitTesting to setup dependencies.

The most obvious solution would probably be test code importing required modules via relative import
from checked out repo, which obviously requires some handling in cases of platform specific code.

The only other possible solution might be to somehow register the tested repo as repository for Package Control, so it would install that rather than latest release.

@rchl
Copy link
Member Author

rchl commented Oct 19, 2024

The hacky solution that comes to mind (which I could probably do in the workflow myself) is to let PC do its thing and then overwrite the dependency in Lib/python38. Then I could probably just have it duplicated in Packages for the purpose of running tests from that directory.

@deathaxe
Copy link
Member

After setup action ST, PC, packages and dependencies are all in place. The test package lsp_utils should be located in Data/Packages folder, already.

What's left to do is to replace Data/lib/python38/lsp_utils with that from Data/Packages/lsp_utils/st3/.

With some luck, packages path is exported as $SUBLIME_TEXT_PACKAGES to $GITHUB_ENV.

@rchl
Copy link
Member Author

rchl commented Oct 20, 2024

I did implement the hack in sublimelsp/lsp_utils#126.

Doing it in a generic way that considers all possible cases would take some more work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants