Clojurians Log v2

I use the following command form when creating new templates (which I do quite regularly several times a month)

clojure -T:project/create :template :practicalli/service :name practicalli/project-name

I use deps-new via an alias rather than an installed tool. An alias allows for default options and additional libraries (I.e. template libraries) to be included (which a tool currently doesn't as far as I am aware) https://practical.li/clojure/clojure-cli/projects/templates/

@jr0cket The issue is for third-party templates in general tho'...

@hlship Can you open an issue on GH so I don't forget -- and I'll give it some thought.

Currently, the template arg is a qualified path into the GH repo so it isn't the repo group/artifact ID. That said, I believe clj-new does have a sort of solution for this using an expanded template arg...

https://github.com/seancorfield/deps-new/issues/55

I have a format for the extended template name -> git repo + deps/root + template-symbol + tag (version), but part of the resolution for that is to add that as a local dependency to the classpath and that bit needs more thought...

(~/clojure)-(!2007)-> clj -Ttools install io.github.seancorfield/deps-new '{:git/sha "047c9650e1005a543bb0c8462e56cebd6c6d9661"}' :as new
new: Installed io.github.seancorfield/deps-new 047c965

Wed Jan 10 01:36:50
(~/clojure)-(!2008)-> clojure -A:1.12 -Tnew create :template io.github.pedestal/pedestal%embedded%io.pedestal/embedded :name what/ever
Resolving io.github.pedestal/pedestal as a git dependency
Creating project from io.pedestal/embedded in ever

Wed Jan 10 01:37:00
(~/clojure)-(!2009)-> tree ever
ever
├── CHANGELOG.md
├── LICENSE
├── README.md
├── build.clj
├── deps.edn
├── dev
│   ├── dev.clj
│   └── user.clj
├── doc
│   └── intro.md
├── resources
│   └── public
│       └── index.html
├── src
│   └── what
│       └── ever
│           ├── routes.clj
│           └── service.clj
├── test
│   └── what
│       └── ever
│           └── service_test.clj
└── test-resources
    └── logback-test.xml

11 directories, 13 files

Wed Jan 10 01:37:03
(~/clojure)-(!2010)->

:1.12 {:override-deps {org.clojure/clojure {:mvn/version "1.12.0-alpha5"}}}

io.github.pedestal/pedestal%embedded%io.pedestal/embedded is pretty much the worst scenario since it's a multi-repo so it requires a deps/root value. The simplest would be io.github.pedestal/embedded -- a separate repo under the pedestal org and then resources/io/github/pedestal/embedded/template.edn as the location of EDN file.

I've gotten around the classpath issue by building a basis, generating a classpath, then spawning a subprocess running Java w/ that classpath to do the actual work.

Yeah, I'm not sure I want to add that level of complexity but it's not off the table. I'm talking to Alex about the 1.11/1.12 tool-running issue and we'll see how that turns out.

The README says: > deps-new only supports :local/root and git-based coordinates, not Maven/Clojars coordinates. (near the top)

I missed that! Would you be open to a PR on this subject?

A PR to do... what?

Allow the template.edn and other files to be on the classpath.

As JAR resources, rather than local files.

From further down in the README: > Note: because deps-new is based on tools.build and uses its file copying functions, the template must ultimately live on the filesystem, so :local/root and git-based coordinates are supported, but Maven/Clojars coordinates are not.

There are surely ways to work around that, either by not using the tools.build functions if they can't work around using Java resources rather than purely filesystem ... or by unpacking the JAR file to the filesystem so that copying can take place.

Getting away from implementation details, do you agree that distribution via Maven repo, rather exclusively by Git coord, would be valuable? I think it would be.

No, I don't agree.

deps-new is specifically designed for local- and git- deps. clj-new supports Maven artifacts but has programmatic, rather than declarative templates (and I'm not actively maintaining that any more really).

As a template creator, I want to streamline the process for my end-users to leverage my template. We have a long-established method of packaging code and resources together, a Maven artifact. deps-new needs a small amount of code, and some resources to generate a project from a template. I fail to see why having that code and resources be file-system based is an advantage.

Now I not only will have to document using -Sdeps, but I'll have to either write docs that say "download this thing and unpack it" or "use the Git URL, sha, and tag".

The issue you created to have deps-new deduce the Git URL and template "name" from the group/artifact will remove the need for -Sdeps and streamline the process.

io.github.pedestal/some-repo or io.github.pedestal/some-repo:some-template will be the full template name. Something like that. clj-new supports something like that for git-deps as I recall?

I never used clj-new, so I can't say.

Because Pedestal is a multi-project, when using a :git/url coordinate, I have to specify :deps/root. Not sure how that's going to work, as it's not something actually encoded into the artifact id.

These concerns are far from universal, but not nearly unique either.

I suppose io.github.pedestal/pedestal:embedded might work, with the embedded suffix turning into a :deps/root.

With the further question on how to resolve, from that, the correct namespace (`io.pedestal.deps`) -- or I'll have to move that code elsewhere.

Hmm, clj-new's git-dep usage isn't as nice as I remembered -- but it predates a lot of the git provider URL deduction logic inside tools.deps. Anyway, I will make this a lot more pleasant when I address that issue.

I can't way to see and try!

Forgive my slightly sharp responses here -- I've had a very trying few days with my partner caught up in the storms in Texas (they were supposed to be back here on West Coast yesterday -- now they should be flying back tomorrow), so I've been holding down the fort here on my own for five days at this point...

I'm headed out to the gym in a few. Expect to see some movement on deps-new and friendlier templates this weekend (my partner will be away again).

Looking forward to it!