Split unrelated content into separate libs

[j0ni]

Tupelo contains a lot of useful but unrelated functionality. This seems at first glance to contradict the culture of small single-purpose tools that pervades the Clojure world.

Would you consider splitting the namespaces into separate projects so projects can cherry-pick the parts they need? I'd be happy to put work into it if you're amenable.

[catalan42]

Hi,

The original motivation was to create a place for all of the functions that
I thought should have been in clojure.core (or safer/easier versions of
them). Hence things like spy, grab, it->, etc. For the things like
Datomic, CSV, parse, base64, etc they are in separate namespaces, also like
the design of the clojure.* namespaces.

If only one or two functions is desired, it is very easy to say:

(ns ...
(:require [tupelo.core :as tc]))
(tc/grab :some-key my-map)

or even:

(ns ...
(:require [tupelo.core :only [grab]))
(grab :some-key my-map)

Both of these are pretty short and don't require thinking about the unused
bits. I'm not sure how many functions are listed on the Clojure Cheatsheet
http://jafingerhut.github.io/cheatsheet/clojuredocs/cheatsheet-tiptip-cdocs-summary.html
but
it makes tupelo.core look pretty small!

Was there something in particular that you think should be broken out?

Alan

On Mon, Nov 16, 2015 at 7:24 PM, J Irving notifications@github.com wrote:

Tupelo contains a lot of useful but unrelated functionality. This seems at
first glance to contradict the culture of small single-purpose tools that
pervades the Clojure world.

Would you consider splitting the namespaces into separate projects so
projects can cherry-pick the parts they need? I'd be happy to put work into
it if you're amenable.

—
Reply to this email directly or view it on GitHub
#2.

[yatesco]

I think infrastructural boundaries are a good pointer. For example, the fact the very useful base64 and it-> (etc.) pull in a postgresql library is a shame.

[cloojure]

OK, all of the SQL stuff is now broken out. :)

[cloojure]

"not" -> "now"

[yatesco]

Thanks @cloojure.

[djhaskin987]

@cloojure,

I hope you keep the library as it is, by and large.

I worked as a build engineer for C++ developers for a while. In that language, dependencies are explicitly expensive: It's hard to even use dependencies, as that language doesn't really have it's own package manager. Because of this, you find libraries in C++ like Boost and Qt, enormous "one-stop shop" libraries whose entire existence is devoted to the notion that dependencies are hard in C++.

I hope to see more of that in other languages. This is because dependencies are hard in every language, and more especially the languages that make it easy to include stuff, like Clojure. The easier it is to include a dependency, the more this cost is hidden. In order to make sure my dependencies don't break me, I must keep tabs on all of the communities that have formed around them. Because of this, I much prefer having everything in one place. This is why leftpad was so painful -- npm makes it really easy to include dependencies, but this means everyone relies on everything. Leftpad is in fact an excellent example of my point -- a small library that everyone relies on, that broke everyone when it broke.

This is why, as the poor sap that must often deal with broken builds often at work, I completely agree with the following principles:

1. Kill your dependencies
2. To use a thing, join its people / mailing lists / gitters

For example, @cloojure, I think the fact that you have the functions json->clj and clj->json in this library is fantastic, because now I don't have to depend on clojure.data.json. all I have to do is monitor how tupelo is doing (join the mailing lists -- do you have one? or a gitter) and in return I get more bang for my buck.

I realize that this is not the "Clojure Way", and that leftpad problems don't often happen. But since the whole point of tupelo is to make it so that missing stuff from clojure.core is no longer missing, I think it's a great idea to let it get bigger. (The namespace clojure.core is, by the way, enormous. Props for taking a leaf out of Hickey's book.)

Thanks, @cloojure!

[laliluna]

Hi all,

I came here to open an issue but found this discussion. Here is my feedback.

I believe it is a library decision to include many things or not. The issue I struggle with is that tupelo pulls in large libraries with a lot of transitive dependencies. The chance to collide with other libraries is very high. I had to remove it as it felled to risky to have so much unused stuff just to use a base64 encoding. I am not sure, if there is a way in Java to use provided scope to avoid pulling in library but I assume that this will still require a lot of stuff at runtime.

Another idea is to create a parent project with modules. This way everybody can decide to use the tupelo-all or only one of its submodule like tupelo-base64

Thank you for your work.

Sebastian

A snapshot of what tupelo is pulling in
tupelo:0.9.138 joda-time:2.10.1 reagent-utils:0.3.2 danlentz/clj-uuid:0.1.7 primitive-math:0.1.4 org.clojure/test.check:0.9.0 io.pedestal/pedestal.service:0.5.5 org.clojure/tools.reader:1.3.2 clojure-csv:2.0.2 org.snakeyaml/snakeyaml-engine:1.0 io.pedestal/pedestal.route:0.5.5 org.clojure/math.combinatorics:0.1.4 org.ccil.cowan.tagsoup/tagsoup:1.2.1 binaryage/oops:0.7.0 binaryage/env-config:0.2.2 org.clojure/data.xml:0.2.0-alpha5 org.clojure/data.codec:0.1.0 io.pedestal/pedestal.jetty:0.5.5 org.eclipse.jetty.alpn/alpn-api:1.1.3.v20160715 org.eclipse.jetty.http2/http2-server:9.4.10.v20180503 org.eclipse.jetty.http2/http2-common:9.4.10.v20180503 org.eclipse.jetty.http2/http2-hpack:9.4.10.v20180503 org.eclipse.jetty.websocket/websocket-api:9.4.10.v20180503 org.eclipse.jetty.websocket/websocket-server:9.4.10.v20180503 org.eclipse.jetty.websocket/websocket-servlet:9.4.10.v20180503 org.eclipse.jetty/jetty-alpn-server:9.4.10.v20180503 org.eclipse.jetty/jetty-servlet:9.4.10.v20180503 org.eclipse.jetty/jetty-security:9.4.10.v20180503 org.clojure/core.match:0.3.0-alpha4 com.climate/claypoole:1.1.4