WIP: Some clj-kondo support #9
Conversation
|
@sogaiu is this still WIP status? |
|
@jjtolton As it might affect newly created projects, I was hoping that at least one other person might try it and share how it went for them 😅 FWIW, I'm not in a hurry on this and happy to come back to it later :) |
|
@sogaui, Does the PR in the main repo clj-python/libpython-clj#135 supercede this or is it complementary? |
|
@jjtolton The short of it is that I think at this point it's better to not have the hooks in the template. To give some background, if as further releases to libpython-clj are made, constructs that the hooks are meant to work for change in certain ways, the particular version of hooks a user has installed need to change appropriately. At the moment (and possibly forever?) that requires user-intervention. If the hooks were to be in the template, then all template-using folks would end up with those hooks enabled, IIUC. Although that may be convneient, it seems likely to lead to folks having hooks enabled without being aware of how to handle the hooks updating process. With the hooks being shipped with libpython-clj itself, one doesn't automatically get hooks enabled, so the out-of-date situation should be unlikely to occur. If hooks are installed, I think it's then likely it was the user who did the installing (famous last words?), so I think they have a better chance of being able to handle an update (which is likely to be almost the same process -- possibly less steps). On a side note, a benefit of shipping the hooks with libpython-clj itself is that it's possible to arrange for a situation where it's much easier to find the right version of hooks for libpython-clj [1]. The alternative before was to obtain hooks from: https://github.com/clj-kondo/config -- but this can lead to version mismatch problems (between libpython-clj and hooks for it) if there are ever changes to libpython-clj hooks. AFAIK, there is no straight-forward way to dig up an appropriate version of hooks for a particular library at that repository -- the easiest thing is just to fetch the latest version, but if your project happens to be using a library version that's not matched to the latest version of the corresponding hooks, you'd need to go spelunking at the repository to try to find an appropriate version. Sorry, this was a bit long. I hope it made sense, but if it didn't, please feel free to say so! [1] That means ensuring that the hooks libpython-clj ships with are kept in sync with libpython-clj IIUC. |
|
Excellent analysis. Might become a bit of a maintenance burden to provide
some kind of upgrade utilities. Maybe I can check with @borkdude to see if
there is an upgrade utility
…On Wed, Dec 9, 2020 at 6:47 PM sogaiu ***@***.***> wrote:
@jjtolton <https://github.com/jjtolton> The short of it is that I think
at this point it's better to not have the hooks in the template.
To give some background, if as further releases to libpython-clj are made,
constructs that the hooks are meant to work for change in certain ways, the
particular version of hooks a user has installed need to change
appropriately. At the moment (and possibly forever?) that requires
user-intervention.
If the hooks were to be in the template, then all template-using folks
would end up with those hooks enabled, IIUC. Although that may be
convneient, it seems likely to lead to folks having hooks enabled without
being aware of how to handle the hooks updating process.
With the hooks being shipped with libpython-clj itself, one doesn't
automatically get hooks enabled, so the out-of-date situation should be
unlikely to occur. If hooks are installed, I think it's then likely it was
the user who did the installing (famous last words?), so I think they have
a better chance of being able to handle an update (which is likely to be
almost the same process -- possibly less steps).
On a side note, a benefit of shipping the hooks with libpython-clj itself
is that it's possible to arrange for a situation where it's much easier to
find the right version of hooks for libpython-clj [1].
The alternative before was to obtain hooks from:
https://github.com/clj-kondo/config -- but this can lead to version
mismatch problems (between libpython-clj and hooks for it) if there are
ever changes to libpython-clj hooks.
AFAIK, there is no straight-forward way to dig up an appropriate version
of hooks for a particular library at that repository -- the easiest thing
is just to fetch the latest version, but if your project happens to be
using a library version that's not matched to the latest version of the
corresponding hooks, you'd need to go spelunking at the repository to try
to find an appropriate version.
Sorry, this was a bit long. I hope it made sense, but if it didn't, please
feel free to say so!
------------------------------
[1] That means ensuring that the hooks libpython-clj ships with are kept
in sync with libpython-clj IIUC.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACPJX425URSUFJTMZCLQ46DSUAD7LANCNFSM4SQ6KDGA>
.
|
|
I think checking with @borkdude may be good. My current understanding is that it's usually a matter of overwriting what was already there. So copying things into place like the original installation. |
|
To avoid version mismatches it's probably best to use the importing functionality as described here: https://github.com/borkdude/clj-kondo/blob/master/doc/config.md#exporting-and-importing-configuration This may need some documentation notes on the library side to explain to users how to use this. |
|
Oh, sorry. I wasn't aware that this project is a template. Generating the hook files as part of a template may work as well, but clj-kondo already has a nice mechanism for this which I linked in the previous comment. |
|
FWIW, I think the PR that was a part of the libpython-clj is set up to do the importing / exporting thing. I think what I referred to as "copying" / "overwriting" above is the same. In my opinion, the "copying" step seems likely to be a conscious decision a user would make, not an automatic upgrade (see below for more on this). That libpython-clj PR is explained here: clj-python/libpython-clj#135 (comment) It points to a comment here: clj-kondo/config#1 (comment) which shows the command used to do the import / export thing: As I understand it, one doesn't usually invoke clj-kondo in this way (at least I don't), which I think is a good thing because you don't "accidentally" change your configuration. So as the docs state:
|
This code has some draft clj-kondo support for the following constructs for libpython-clj:
import-pythondef_pylib_fnIt also includes an attempt to handle
export-symbolsfrom tech.parallel.To test it out:
If you have a very recent tools.deps clj installation (having
-Xsupport) the following invocation can be used to generate from the template:For a not-as-recent clj installation:
Upon success a
libpython-clj-kondoproject directory should be created.One way to see the effects is to first replace the generated
src/libpython-clj-kondo/libpython-clj-kondo.cljfile with the following content:Then run a recent clj-kondo on it:
There is only one warning. Without the hooks, one would likely see something like:
Alternatively, in an editor with clj-kondo, view the file.
Note that if libpython-clj or other portion is updated in one's project, the corresponding clj-kondo hooks information may need to be updated depending on the nature of the changes in the updated dependencies.