Run sync_with_poetry after changing the .pre-commit.config.yaml about sync_with_poetry HOT 11 CLOSED

Thanks for your response @floatingpurr , it is clear now!

from sync_with_poetry.

Hi again @davidsampimon! The rational behind this mechanism is pulling versions of python packages from poetry.lock, and then updating corresponding python-based hooks in .pre-commit.config.yaml (but not backward!). That's the reason why this hook is tightly coupled with poetry.lock.

Can you provide more details about your use case?

PS: pre-commit lets users run this hook manually, if necessary.

from sync_with_poetry.

Sure, we use poetry for all our projects and our CI/CD pipeline requires that all projects have certain linters/formatters as dev dependencies (black, flake8 etc.). So every project starts out with a poetry.lock file with those dev dependencies already included.

Since using pre-commit is not required on our projects, it is quite common that this is set up in a later stage. What then often happens is that the individual devs do not pay attention to the linters/formatters already present in the poetry.lock file and use a different version in their .pre-commit.config.yaml file.

I was hoping that with 'sync_with_poetry' we could check the rev tags each time there is a change in either .pre-commit-config.yaml or the poetry.lock file to make sure the poetry.lock file is respected

from sync_with_poetry.

Since using pre-commit is not required on our projects, it is quite common that this is set up in a later stage. What then often happens is that the individual devs do not pay attention to the linters/formatters already present in the poetry.lock file and use a different version in their .pre-commit.config.yaml file.

That's exactly the reason why this library exits. You can use poetry.lock as a single source of truth about versioning of all your python-based ecosystem.

I was hoping that with 'sync_with_poetry' we could check the rev tags each time there is a change in either .pre-commit-config.yaml or the poetry.lock file to make sure the poetry.lock file is respected

I see, but sync_with_poetry is just a pre-commit hook. As the name says, pre-commit runs upon commits, acting as a sentinel before cheking modifications in a codebase. You can also run it manually and on specific files. So, you can definitely set up a mechanism to run sync_with_poetry upon save, or according to your needs (e.g., https://betterprogramming.pub/automatically-execute-bash-commands-on-save-in-vs-code-7a3100449f63)

from sync_with_poetry.

Ok, so why isn't sync_with_poetry run on changes of .pre-commit-config.yaml? I would expect it to enforce the rev defined in the poetry.lock, so that the revs aren't changed for example when (accidentally) running pre-commit autoupdate.

from sync_with_poetry.

Hi @real-yfprojects, swp works the other way around. You use poetry to manage your dependencies, and swp synchronizes the pre-commit packages accordingly. The reverse way is not supported.

from sync_with_poetry.

Hi @real-yfprojects, swp works the other way around. You use poetry to manage your dependencies, and swp synchronizes the pre-commit packages accordingly. The reverse way is not supported.

I know that and I am not requesting that at all. I also know that I already expressed clearly what I am asking for. Please read my comment again. If you still don't understand, I will try explaining it differently.

from sync_with_poetry.

Hello again. To be honest, I do not understand the reason why swp should be involved in your use case. Why should you run swp upon changes on .pre-commit-config.yaml? This looks like an anti-pattern, given the rationale of this package.

Even if you accidentally run pre-commit autoupdate, there are many ways to revert back the modifications (e.g., undoing local changes with git or manually running swp again to fix just the versions of packages controlled by swp). Moreover, all the hooks are run before each commit, so swp will sync versions anyway.

from sync_with_poetry.

there are many ways to revert back the modifications (e.g., undoing local changes with git or manually running swp again to fix just the versions of packages controlled by swp

But that is not the idea of pre-commit hooks. I could run all my pre-commit hooks manually but I don't want to. They should be run automatically before each commit so that each commit in my git history has a valid state (as defined by my hook configuration). From a maintainer perspective, I only have to tell contributors to use pre-commit and pull request will need less cleaning up (e.g. by squashing).

Moreover, all the hooks are run before each commit, so swp will sync versions anyway.

Only if you run with --all-files as pre-commit.ci does. Otherwise they will only run if one of the configured files changed.

from sync_with_poetry.

I see, but I'm still not convinced that running swp upon each modification on .pre-commit-config.yaml by default can be a good pattern for general usage. In addition, the config option should be modified accordingly.

Can overriding the file pattern in your very specific hook mapping be an option to tackle your problem?

from sync_with_poetry.

Can overriding the file pattern in your very specific hook mapping be an option to tackle your problem?

Already did that, but I thought that it would be a sensible default.

from sync_with_poetry.