Fork me on GitHub
#tools-deps
<
2021-07-08
>
hiredman03:07:05

You could even setup syncthing between your local m2 and remote m2, and wrap the above clj call in a single ssh command

vlaaad08:07:01

What's the stance on renaming existing libraries to use reverse domain names (e.g. vlaaad/remote-repl -> io.github.vlaaad/remote-repl)? Should I do that? Should I also rename the root package?

seancorfield17:07:15

I renamed all my popular libs over a period of three or four months, double-publishing them under both the legacy group ID and com.github.seancorfield for a while (I am no longer doing that). antq seems to correctly detect this migration and will suggest the group change along with any version change when you run it against your deps.edn files. I did this partly to raise visibility, partly because clj-new (and depstar) are trying to be "model citizens" and clj-new now generates new projects that follow this group/artifact pattern, and partly so that any new libs I release -- which have to go into a new VGN like com.github.seancorfield -- will be consistent will my existing libs. And that just happened with the latest version of what was expectations/clojure-test since the tooling involved in supporting cljs (new in the 2.0 version of the lib) filters out JARs whose names start with clojure so I had to change the artifact ID, which meant I could not publish it under the old non-VGN group ID!

mpenet08:07:59

I personally do com.foo/lib-name and use foo.lib-name as root namespace in clj code, so foo.lib-name/do-something etc

rickmoynihan08:07:30

@vlaaad: What is the point? I thought the main purpose of the io.github.user/project convention was so git deps didn’t have to specify a :git/url and to make the artifact name for git deps less arbitrary. Changing the artifact name for a maven dep seems like it’ll only cause pain (unless you also change the root package); but it feels like pointless churn to me.

rickmoynihan08:07:58

In the case of git deps, one thing I’m not clear on is whether io.github.user/project and user/project {:git/url ""} will canonicalise to the same thing? If so what about ssh urls?

vlaaad08:07:25

Yeah, I'm inclined to think changing the name will only cause confusion and errors...

dominicm09:07:37

I would discourage you unless you're really sure. I predict a lot of pain in people's future if a lot of projects migrate without considering the transitive dependency clobbering problem.

rickmoynihan09:07:31

Yeah my point exactly

Carlo11:07:46

which branch should I use for add-lib @seancorfield? I understand the idea is a few years old now, is there some particular reason it has not been merged?

Alex Miller (Clojure team)12:07:40

The most recent one is add-libs3. It hasn’t been merged because we have not decided on various aspects of the api and integration

🙌 3
seancorfield17:07:42

The :git/url and :sha in my dot-clojure repo is pretty much always up-to-date for that, along with usage examples: https://github.com/seancorfield/dot-clojure/blob/develop/deps.edn#L202-L228

🙌 4
Alex Miller (Clojure team)12:07:40

On the renaming question, I do not see any reason to rename any existing thing. Unless maybe it is a tool, and you want to make it easier to install, and no one else depends on it as a dep

👍 13
vlaaad14:07:25

Not like anyone cares, but I rewrote remote-repl's deploy script to a pure clojure (no more bash/powershell). It's nice to iterate on build script in the REPL. The biggest part is pom, mostly because depstar doesn't put commit sha to pom's scm tag. In the end I decided to just create the whole pom from code — and look https://github.com/vlaaad/remote-repl/blob/master/build/build.clj#L40-L76 with Clojure!

seancorfield17:07:11

We just switched out our build bash script at work for a build.clj "program" instead and we're liking that switch.

Alex Miller (Clojure team)14:07:41

that will be even easier with tools.build :)

vlaaad14:07:45

Yay, that's what I hoped to hear :D

rickmoynihan08:07:09

Actually you obviously have seen it; as the naming convention thing was I think first mentioned here

vlaaad10:07:47

I've seen it live :P

vlaaad10:07:35

It had that sweet copyright infringement at the beginning :D

dharrigan14:07:46

Is my understanding correct, that it will be a combination of deps.edn to define -X functions and tools.build to provide a toolchain?

Alex Miller (Clojure team)15:07:42

well more you write a build program that uses tools.build, then use -X (or really -T but same idea) to invoke it

dharrigan15:07:53

thank you 🙂

seancorfield17:07:15

I renamed all my popular libs over a period of three or four months, double-publishing them under both the legacy group ID and com.github.seancorfield for a while (I am no longer doing that). antq seems to correctly detect this migration and will suggest the group change along with any version change when you run it against your deps.edn files. I did this partly to raise visibility, partly because clj-new (and depstar) are trying to be "model citizens" and clj-new now generates new projects that follow this group/artifact pattern, and partly so that any new libs I release -- which have to go into a new VGN like com.github.seancorfield -- will be consistent will my existing libs. And that just happened with the latest version of what was expectations/clojure-test since the tooling involved in supporting cljs (new in the 2.0 version of the lib) filters out JARs whose names start with clojure so I had to change the artifact ID, which meant I could not publish it under the old non-VGN group ID!

Alex Miller (Clojure team)17:07:01

> filters out JARs whose names start with `clojure`

seancorfield17:07:31

I was pretty gobsmacked by that too... apparently it's something doo does? https://github.com/bensu/doo (I don't do cljs so this came from @kkinnear as part of three PRs to add standalone cljs support to the lib).