Third party dependency sync

[va1ha11a]

Hi David and Community,
Really enjoying using the polylith setup so far.
I am currently looking at using it for some more mission critical stuff and I have a concern about 3rd party deps in the dev and test environment not being the same version as the project environment used to deploy from.
Firstly, is this correct:
Say for example I play with an idea in dev with fastapi then a while later I end up constructing a project from it and add fastapi to the project directory there is noting that ensure the versions are the same unless I check this myself, is that correct?
Secondly as I understand this is also an issue for running tests, the tests may run with different 3rd party deps.

If that is correct does anyone have any mitigation suggestions for this?

[DavidVujic]

Hi @va1ha11a,

You are correct, currently the tooling support for checking the third-party dependencies is sparse. There is the poly check command that will assert that there are no missing dependencies. But if you would bump the version in the development environment, there is currently no automation to check that the actual versions are in sync. That would need a manual step - an active decision for each project.

So basically, a developer checklist is needed:
is the dev lock-file (or the deps in the pyproject.toml) altered -> check if there is need to bump the projects too.

In addition to poly sync (and also poly libs) you can run the services locally or in Docker to verify that a project runs as expected. In the example repo I have added some docs and an example Dockerfile that might be useful: https://github.com/DavidVujic/python-polylith-example/blob/main/projects/my_fastapi_project/README.md

[va1ha11a]

Thanks David,
I am also having a look at some other bits and pieces like pytest-env to see if I can get a good test work flow that at least tests in an "as will be packaged" state.

I am keen to see if I can find a way to make one lockfile a subset of another and/or constrained by the other.
I will post up whatever seems to work out for me, but if anyone else has thoughts let me know

[va1ha11a]

Posting where I am at in case anyone is heading down the same road.

I am not 100% happy with the approach but it seems mostly workable for testing so far:

1. Use rye as package manager (or any that installs from requirements.txt type lock files)
2. Create the workspace and package pyproject.toml as normal using poly tools
3. Create a manual script to keep the lock files in sync using pip-tools or uv: uv pip compile workspace-x/projects/proj-x/pyproject.toml -o workspace-x/projects/proj-x/requirements.lock -c workspace-x/requirements.lock
   This should produce a subset list of requirements for the project and hence validate testing in the worksapce venv

I guess as long as this script is run prior to build it should be the only time required so hopefully adding to the build script / process is not a big deal.

Any other ideas or issues with this approach are welcome.

[DavidVujic]

I have updated the poly libs command to visualize the added third-party inports in the projects, and if the versions differ. This command will compare what has been defined in the pyproject.toml files of the projects (and not the actual usage that is defined in a lock file).

I hope this update will improve the developer experience and help developers catch any typos in the project config!

Details in Pull Request: #186