I suppose I could use replace-deps/paths in said alias...

Yes, for tools unrelated to your main deps you should use this

Kinda clunky when I have a tool that I usually use together with my main deps but every once in a while I want to use it on its own

Still doable

Working on such a thing now actually

ooh nice one!

> a command that tells you the functions in a namespace you can invoke (all public? all with particular meta? all doc'ed? filter to 1-arity? lots of open questions) Conceptually, I view choosing a function and specifying the arguments as orthogonal. The arglist is either a map for a function designed with cli -X in mind or a sequence in the general sense. It is a tricky problem since at some point you're better off just writing the command into a script instead of typing it at the command line. > a command that tells you help for a namespace (probably the ns doc string) I've used several of the cli "toolbelts" (aws, heroku, git) and started toolbelt projects at a few of the places I've worked. One of the reasons I think the clojure cli is particularly exciting is that it's potentially an open toolbelt. Maybe it would be better as a 3rd party library, but the idea of being able to find cli tools using the cli tool itself sounds appealing (eg. cli find linter to find linter tools). The syntax isn't consistent, but hopefully the idea makes sense. I also like the idea of being able to copy seancorfield's deps.edn into my .clojure/deps.edn and then run a command like cli ls to list all of the aliases and associated commands. These suggestions gloss over all the details of how the cli tool would be able to discover cli tools on the internet or from a deps.edn file, but adding discoverability makes it easier to find the right tool as a user and have your tools be found as an author.

@smith.adriane

(! 847)-> clj -A:deps
user=> (require '[clojure.tools.deps.alpha :as t])
nil
user=> (->> (t/find-edn-maps) ((juxt :root-edn :user-edn :project-edn)) (t/merge-edns) :aliases (keys) (sort))
(:1.0 :1.1 :1.10 :1.10.0 :1.10.1 :1.10.2 :1.2 :1.3 :1.4 :1.5 :1.6 :1.7 :1.8 :1.9 :add-libs :bench :check :classes :closh :comp :decompile :deploy :deps :depstar :dev :eastwood :expect :graph :install :j14 :jar :jedi-time :liquid :master :measure :new :nrepl :outdated :pne :portal :prepl :readme :rebel :rebl :reflect :reveal :runner :socket :socket-rebl :socket-zero :spec2 :test :uberjar :dev/repl)

Just FYI, that's how to find all the available aliases in any given project or non-project context.

My example is more of a hypothetical for someone picking up deps.edn. ie. How do I get up and running with a reasonable set of tools at my disposal?

Also, not sure if you're aware but :exec-args can be a keyword, and it is looked up as an alias to get the data structure that is the actual :exec-args map -- and tools can do the same thing (as depstar does and I believe deps-deploy soon will too).

Yeah, the absolute "getting started" (with deps) part is still a bit fiddly. My comment there is if you at least start with clj-new and create a new project that way, it'll already have the aliases you need for testing, building a JAR, deploying to Clojars etc.

But of course clj-new is opinionated about how to do those things and it's encoded in the built-in templates, and other new-project templates will be similarly opinionated in a different direction.

And of course there's also tools.build on the horizon.

Yep, I use clj-new, but I have to either reuse the clj-new command that's in my bash history or go to the clj-new readme every time I use it

I have the clj-new aliases from your deps.edn, but the clj-new docs don't actually use those

Which part(s) of the invocation are hard to remember?

I don't create new projects that often and when I do, it's usually after copy and pasting the command from the github readme, so I never remember which keys are required

; my .clojure/deps.edn:
  :new {:extra-deps {com.github.seancorfield/clj-new {:mvn/version "1.1.264"}}
        :exec-fn clj-new/create
        :exec-args {:template lib}}
; the clj-new readme:
   :new {:extra-deps {com.github.seancorfield/clj-new
                         {:mvn/version "1.1.264"}}
            :exec-fn clj-new/create
            :exec-args {:template "app"}}

I could sync those up if I knew which was the more likely to be used 🙂

fwiw, I think the docs for your dot-clojure, clj-new, and depstar are really good. It's mostly just that • there's no 0 arg version that makes sense • I use the tools infrequently enough that I don't remember the keyword names that are required • there's no way to figure out which options are available without going to the github readme page

I'm not sure how cli tool authors provide a way to display options and examples except github readmes.

the best work around that I can think of is for tools like clj-new to provide a 0 args version that prompts for any required/common options

then I can just do clj -X:new and it can prompt me for the project name and template

it's also totally possible that I'm doing it wrong. My intention was to use it like the aws cli toolbelt, but that might just be the wrong way.

(! 848)-> clj -X:new
Usage:
  clojure -m clj-new.create template-name project-name options

or:
  clojure -X clj-new/create :template template-name :name project-name options

Any additional arguments are passed directly to the template.

The template-name may be:
* app - create a new application based on deps.edn
* lib - create a new library based on deps.edn
* template - create a new clj template based on deps.edn

I agree that isn't quite as consistent and helpful as it could be.

(part of the problem there is not being able to tell how something was invoked since that information is gone by the time the tool is invoked)

So clj-new would need to introspect the available aliases, see if :new was available and what it was aliased to, and then somehow weave that into the help.

Since you could be doing clojure -Sdeps '...' -X clj-new.create ... and not even have an alias available.

actually, the help text for clj -X:new is exactly what I need. I guess I just never tried it. 😳

hmm, actually, neither of the example commands work when I copy and paste them into the terminal. I guess that's since the cli tool doesn't know how the command was invoked as you were saying. It does solve my specific problem for clj-new though since I now have a way to look up the options without going to the github readme.

I will update the help so it's a bit "smarter" about things...

https://github.com/seancorfield/clj-new/issues/55 -- feel free to add more notes there.

> A command that tells you the functions in a namespace you can invoke (all public? all with particular meta? all doc’ed? filter to 1-arity? lots of open questions) I’ve been thinking about this as well in the context of cli entry point for Reveal. I wanted to have a single entry point ns accessible both from code and from cli, but some functions that are definitely a public API don’t make sense to use from cli (if they are e.g. have to be composed with other functions). Given that, it made sense to use particular meta. There is also another question that’s not asked — how to show a short description of a function vs a full documentation. Given an ns, it makes sense to get some quick overview of what functions are there before diving into details of a particular function. There were a couple of options, and the most pragmatic to me seemed treating very first line of cli docstring as this short description. The whole code for that is here: https://github.com/vlaaad/reveal/blob/master/src/vlaaad/reveal.clj#L159-L182

@U47G49KHQ that’s similar to the approach I took for inclined:

clj -Sdeps '{:deps {eval/inclined {:git/url "" :sha "a40aeeba2d471f19e83eeeceb3ebbc700f23185f"}}}' -M -m inclined.main -h