|
so I feel like there might be something really wrong with the way julia is currently approached in pre-commit -- and honestly I don't have any experience in julia and mostly have been leaning on contributors to have that knowledge I suspect that we're approaching installation in a way that doesn't really represent how a julia package would get normally installed. for instance in python when you pip install . it will appropriately copy the files it needs to the particular environment it is being installed to! in julia it seems like we're manually doing that copying and we're manually specifying the list of files to copy -- that to me seems not quite correct 🤔. I imagine we're missing some sort of "pack" step (ala what language: node does) or some sort of other package manager manipulation. ideally we'd be in some place where we're not manually copying files out of the source repository and just running some julia installer command to do the right thing. what we're doing now seems fragile -- and this PR also seems kinda fragile (I'm not even sure source files are required to be in src for instance). do you have experience in julia that you could lend some advice? this seems odd either way |
Sorry, something went wrong.
|
Just starting to look into pre-commit for Julia myself, so take this with a grain of salt, but perhaps the hook packages should be installed with Julia's package manager Pkg instead of the files being manually copied? If this has to happen from Python, then PythonCall.jl might be a solution? |
Sorry, something went wrong.
|
This does feel a bit weird, I agree. The case here is when the precommit hook lives in a package, like JuliaTesting/ExplicitImports.jl#128. The existing hook support copies the Project/Manifest from the directory the hook lives in and tries to install the dependencies. But if the Project corresponds to a package, it (a) refuses to use Pkg to install that package as a dep (since the project name/uuid matches) and (b) fails as it lacks the src code. An alternative way to use hooks that does work is to create a separate repo for the hook (outside the package) and use a Project.toml there to specify the package so it can be installed. This is done for example here: https://github.com/fredrikekre/runic-pre-commit. However I think it’s pretty inconvenient to maintain a second repo just for precommit support. Precommit is not a main way people use ExplicitImports for example, and it’s easy enough to add a hook file, but it’s a bit more to need to update/maintain a Project in a secondary repo. The reason copying src feels ok in the scenario to me is that with the current setup is that we copy the Project.toml and when that is for a package, it needs the src code to run. So it is an expansion of the existing Project support. Either way, we definitely do not need PythonCall. We already install deps. The question is just how to do it when the hook lives in the package itself. |
Sorry, something went wrong.
|
Why not copy everything? Disclaimer: I'm also just starting to look into pre-commit for Julia myself. |
Sorry, something went wrong.
Copies src files in addition to Project/Manifest. This allows pre-commit hooks to live inside a package (like https://github.com/JuliaTesting/ExplicitImports.jl/blob/main/.pre-commit-hooks.yaml) instead of being in a separate repo (like https://github.com/fredrikekre/runic-pre-commit).
Split out from #3494