clojure morsels goes out this week (or early next week if time ends up tight), so if there's something that ought to be shared about this effort let me know

Slack question, I've been bookmarking conversations, should I be copying and pasting those into a file somewhere? Not sure the slack setup if those conversations stick around or not

Direct link to this stream on Zulip would be https://clojurians.zulipchat.com/#narrow/stream/180378-slack-archive/topic/improve-getting-started

Thanks all

Yea that is pretty handy clx @babashka/bb run build 🙂

you're about 90% of the way there combining clojure cli and find-versions from git deps and tools/install

% clojure -X:deps find-versions :lib com.github.seancorfield/deps-new
{:git/tag "v0.1.0"}
% clojure -Ttools install com.github.seancorfield/deps-new '{:git/tag "v0.1.0"}' :as deps-new
Installed deps-new
% clj -Tdeps-new app :name foo/bar
Creating project from org.corfield.new/app in bar

given the github org/project name, you can call the first command. the versions are sorted, so the last line is the newest. given the org/project + last coord, call the second command at that point, you have the tool installed with a local short name (the :as at the end), which you can then invoke

we could probably make something that did the first part as a single step like

clj -Ttools install-latest com.github.seancorfield/deps-new

That is super cool

clojure -Ttools install can install a tool from Maven, Clojars, git deps, or even from somewhere locally. While I am testing deps-new, I'll often do clojure -Ttools install com.github.seancorfield/deps-new '{:local/root "."}' :as new so I can test clojure -Tnew ... in another directory.

logged at https://clojure.atlassian.net/browse/TDEPS-206

the downside of installing a tool from maven is that you don't get the deps usage features with that

I'm not sure that will always be the case but it's a big TBD right now

I think we should probably encourage more git deps and source-based installs -- I have quite a few things in my deps.edn that are git deps, as well as my ~/.clojure/tools folder (which is where clojure -Ttools install puts things)

(right now the only reason I still publish some of those tools/libs to Clojars is because of cljdoc -- but they're working on being able to import git deps now)

I think for tools, git deps are better in most cases (not ideal in cases where you want to proxy the net for control though, where a maven proxying repo like Nexus can be used)

probably we have strayed from the intent of the channel at this point :)

No, I think knowing the the CLI / git deps / tools is already available and gets us close to npx usage is valuable -- but it makes it clear there's a documentation gap since that information isn't widely known yet.

I'd be happy to write a guide focused on tool use, that stuff is pretty buried right now

Do you think some of this should be up front in the Getting Started page? Although I guess the downside is mentioning specific tooling would sort of "bless" that at the expense of other community projects. deps-new as a tool to quickly create new app/lib projects -- which have fully-fleshed out deps.edn files that include testing, building JARs, deploying (to Clojars).

(I plan to modify the templates for deps-new to use tools.build more "soon")

I actually rewrote the entire Getting Started area in January but it's still pending some stuff so hasn't been merged

Ah, OK.

with respect to deps-new, I think it's useful in some cases, but really the big thing with deps is you shouldn't need it to get started. with git deps and git publishing, you don't need to build jars or deploy to clojars

I got invited here by Clojure Morsels on Twitter, and thought I'd chip in. In particular the clj command line tools arguments are hard to understand, or memorize. In comparison to tools like npm, yarn, things like -X, Ttools, seem odd at the very least. Is there a particular reason for this complexity and/or room to improve that?

Lein, for example, is a lot friendlier in terms of commands to remember.

lein is pointed in a different direction than the Clojure CLI, which is a generic program runner with dependency support.

Take for example this: clj -A:test -Spath, which is used to apply a classpath modification and examine the modified classpath, if I understood the docs clearly. Yet I have no idea what the -A stands for, or why (what I assume) classpath is stated as -Spath and not just classpath.

well, you can bike shed every decision here. like any software, there are historical reasons how we got here

regrets, I have a few

Not at all my intention, honestly. I'm just trying to figure out if there is room for improvement or not, because it is very hard for anyone new to actually know how to use this tool without constantly referring to the documentation, and flat out trying to memorize the commands somehow. The idea is to make using Clojure easier here, no?

And perhaps this is by design, and that's fine then.

certainly open to ideas to make it better/easier, but those also need to be balanced against backwards compatibility and the overall design goals. I don't understand how you can use any tool without learning how to use it.

Sure of course, but there is a big contrast between a tool with clear english terms, and a tool that uses acronyms (acronyms+word?) instead, which while it would not eliminate learning, it would make the learning easier.

I wonder if there would be room for adding command aliases, which would keep the original functionality intact, but allow it to be used in a more verbose way?

Is npx really any easier to learn/use though? Serious Q.

npx [options] <command>[@version] [command-arg]...

       npx [options] [-p|--package <pkg>]... <command> [command-arg]...

       npx [options] -c '<command-string>'

       npx --shell-auto-fallback [shell]

git uses a lot of English words but I still find it largely inscrutable when I don't understand the underlying model

I don't think this is a useful argument to have though

what is useful is to hear what you find confusing

What I mean by command aliases, is that often times those starting out prefer to use a full descriptive commands as they are easier to remember/reason about. Say instead of clj -X they could run clj run or clj --execute . Over time as users get more comfortable/used to a tool, they also tend to start using the shorthands like -X for things, but having everything be -X, -A, -S and what-not by default is daunting and off-putting. Just my $0.02, and I understand I may be in the minority thinking this here and that's fine.

it is useful for you to share this, thanks

we don't know whether it's a minority or common opinion unless people share things :)

we can still add things while keeping the old stuff for backwards compatibility

yes

was your response meant to be "clj could potentially do some of these sorts of things just in a backwards compatible way"? or "clj can be changed in backwards compatible ways (but probably won't anything like those changes)"? I was pretty sure it was the latter

oh sorry, I misread your question (isn't/is)

(oops, I misread it too!)

I think it is conceptually possible to both support a new command style and also be backward compatible with the old style

(and that's partly because clj script is deprecated in favor of clj -M script now -- and so clj command args could be possible in the future?)

sure

or there could be a different command

(like a clx script that built "traditional" arguments/options and invoked clojure maybe 🙂 )

FWIW, this sort of thing was partly why we had a build shell script at work so we could translate high-level "commands" into low-level clojure invocations, so that test would expand out to -X:test:plus:lots:of:other:aliases etc.

composite aliases is another thing to eventually look at but I think that's a separate problem

super glad the logbot is here now for ^

At Exercism we're developing code analysis tooling for the purpose of identifying common errors and providing automated feedback, in an effort to save human mentorship for where it is better suited - the uncommon errors people make. Any silly mistakes we can address before a solution enters the mentoring pipeline helps accomplish this goal. I'm mentioning this here because so many people go there to learn Clojure that it represents a significant chunk of our collective "educational canon", and it's not a huge exaggeration to say that any effort invested in this project has the potential to reach infinitely many students. If this sounds like fun to anyone else I could definitely use some help because I'm the only one working on it for some reason. Even if just to bounce ideas around. I'm happy to take this on but I've never developed tooling before so I'm just figuring it out as I go. https://github.com/exercism/clojure-analyzer