David Seddon

> And is some case, like I've demonstrated, installing certain packages together is not even possible This is an interesting one. Import Linter is designed to work within a single...

> package-a and package-b might depend on conflicting versions of core, so all three packages cannot be installed in the same environment. It's just not possible. This is the aspect...

Hi James, There may be an underlying reason why that isn't working. Take a look at https://github.com/seddonym/impulse, which has a similar structure. You can run Import Linter by doing `uv...

Thanks for sharing James - I see the issue in this case: uv doesn't automatically add `src` to the Python path as the project is not created as a [packaged...

Fair enough. I've changed my mind - I would definitely consider a PR adding a `source_roots` option, if anyone wants to contribute.

Hi, thanks so much for raising the issue. I am aware of Tach but haven't used it in a real project myself. I don't intend to fork or merge it...

> Also, for what it's worth, I've made a script that wraps grimp to automatically infer plausible layered architecture contracts for an existing project Wow your tool is so cool...

The hook mechanism could work by specifying `contract_builder` functions in the top level configuration. ``` [importlinter] root_package_names = mypackage anotherpackage contract_builders = myproject.contract_builders.build_foo_contracts somelibrary.build_bar_contracts ``` That wouldn't allow dynamic generation...

Another approach might be to support some kind of templating language like `jinja` and allow a hook to pass in variables.

Thanks for raising. I'm afraid it's not currently possible without listing them explicitly in `root_packages`, otherwise they won't be included in the import graph that is used to check the...