-
Notifications
You must be signed in to change notification settings - Fork 12
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
Support SDW components that manage dependencies using poetry #459
Comments
I'd be game to take a stab the necessary scripting changes identified here, unless you or another team member prefer to work on it. To recap my understanding:
I would suggest implementing this, for now, in a backwards-compatible manner, so we don't have to migrate all repositories to Poetry at once. We could maybe try moving a small repo like |
I've got a One thing I'm wondering is if we should migrate from |
Whatever ends up being simpler I think. Normally I'm in favor of jettisoning extra dependencies, but setuptools is key enough to the entire Python ecosystem that we're going to end up depending on it regardless. Also setuptools has a long history of being stable and reasonably well maintained.
I was thinking we could just do |
Turns out we're already installing the older I've tried parsing securedrop-proxy's |
I ended up just sticking with As I go I'm updating some parts of the documentation and code comments that seem outdated or potentially confusing (e.g., I'm avoiding references to a "PyPI mirror" since I don't think that's the best terminology to describe our use of a local wheels directory without an index). |
Progress update:
Side quest:
|
OK, I'm happier with
I'll try that for now. |
I took the easy way out for the source download step: This means we'll want From reading about CI is now fully green on |
.. he said foolishly, taunting the dependency demons. #464 looks like it'll be a good chunk of work and we may want to have "the conversation" first, of whether we really need to localwheel our localwheel-building environment (:xzibit:). In any event, I just added a smol utility function for now that should do the trick. |
poetry has a lot of dependencies (comparatively) as it doesn't vendor them like pip does, which means adding it into the bootstrap is going to be a lot of work. I would suggest we avoid needing to bootstrap poetry by just installing it from Debian packages. The only problem with doing so is it only shipped in bookworm, so we either wait for us to drop bullseye support or implement #460 in a way that lets us run different steps of the process with different containers/OSes. So maybe in the short term we just try to avoid running poetry? :/ |
Yeah, that's the conclusion I landed on as well - |
We parse
requirements/requirements.txt
in a few places, those need to be updated to parse poetry.lock. This should be easier since it's a TOML file, but also that means we need a TOML library for bullseye since it's only in the standard library with bookworm.Places needing updates (may not be complete):
pip download
The text was updated successfully, but these errors were encountered: