Leaner dep tree?

[vemv]

Hi there,

In two of the tooling projects where I envision eventually integrating zprint, keeping dependency trees lean matters. They're vanilla JVM/Maven artifacts to be included as a project's :dev dependencies so the less stuff there is, the less likely it is for conflicts to arise.

zprint's tree seems pretty small. Other than rewrite-clj, there's sci, which has a few transitive dependencies.

From the quick look I gave it, it seems Sci is used for the ;!zprint feature. I would be fine living without it. In fact I don't really like inline comments for tooling - have rejected that choice in a couple projects of my own and find it quite a distraction when working day-to-day with linters or such.

(If you are super curious, here's how an alternative approach looks like)

So my suggestion would be for instance, to internally split zprint into e.g. zprint + zprint-core. zprint would depend on sci and zprint-core.

And my own projects would depend only on zprint-core.

Please consider this a low-priority request - simply keeping it in the hammock would make me happy!

Cheers - V

[kkinnear]

It turns out that there is at least one project I would like to use zprint for where sci cannot be present, so that your proposal is not out of the question.

As it happens, though, sci is used for reading all option maps (not just the ones in the comment API). This is for safety -- the options maps have to be able to have functions defined within them, and only sci will allow me to read them and have executable functions which run in a "sandboxed" environment where they can't affect anything outside of the insides of zprint. Prior to using sci there were places you could define functions in option maps and places where you couldn't, and it was quite confusing. sci solved that problem quite neatly.

So, were I to create a zprint.core without sci, it would likely be one that didn't read in any option maps from files. Now, that might be exactly what you want (and/or even expect).

There is already a way to configure zprint to not read any files when it starts up, if that is interesting to you let me know, and I'll fill you in on how it works. By default it looks for ~/.zprintrc or ~/.zprint.edn and, based on what is found there, might look for other files in other places.

Anyway, I hear you about small dependency trees. zprint's is pretty small now, and I may well bifurcate it to make it even smaller it in the future for one portion of zprint, but I have no immediate plans to do so.