Projects that have dynamic names don't work

[pmonks]

trafficstars

We have a single project (fn-fx) that emits two separate artifacts, under different names:

1. https://clojars.org/fn-fx/fn-fx-javafx
2. https://clojars.org/fn-fx/fn-fx-openjfx11

It appears that versions doesn't handle that properly, as our dependency status badge is no longer functional:

Note: this may be another symptom of issue #5.

[danielcompton]

Ouch, yeah the trouble with this is that the project.clj parser doesn't execute any code which is what's needed here to distinguish between the two versions. Will have to noodle on this further.

[pmonks]

Here's a possible idea (that may be completely off base, so feel free to shoot it down if it clearly won't work):

Instead of trying to read project.clj files as static data structures, why not just run a leiningen plugin that checks dependencies and updates whatever data structure(s) the versions front end uses? That way you can leverage all of leiningen's built-in magic for "free".

This might even be as simple as just running something like lein-ancient, and then twizzling the output a bit.

[danielcompton]

The issue with reading it via a Leiningen plugin is that that causes arbitrary code to be executed. The trick is doing this safely. If I just do this on the Heroku server then I will have arbitrary code execution on the same server, not ideal...

To solve this in the general case I think you'd need to use something like Lambda or a similar isolated code execution environment.

[pmonks]

You could execute the leiningen + custom plugin in a container, then throw it away as soon as it's done. The only thing that would survive the container would be whatever data the custom plugin emits (project name, version, dependency graph, etc.). Given that you control the plugin, there's almost no risk of arbitrary code somehow "escaping" the container.

This is how services that are fundamentally based on arbitrary code execution (e.g. TravisCI) handle this kind of thing.

[danielcompton]

Yep, that's what I need to do, it's just a tricky problem to solve safely.

[pmonks]

Containers provide a safe sandbox in which to execute arbitrary code, and the only component that will be touching the environment outside the container (the custom leiningen plugin) is entirely under your control.

[pmonks]

There's even this library to make managing the temporary container easier.

[vemv]

For anyone else finding this issue, an alternative approach would be to use the antq lein plugin as a github action, and then self-hosting a badge