Git Product home page Git Product logo

deps-new's Introduction

deps-new Slack

Create new projects for use with the Clojure CLI and deps.edn.

Intended to be installed as a "tool" (Clojure CLI 1.11.1.1149 or later).

clojure -Ttools install-latest :lib io.github.seancorfield/deps-new :as new

Note: if you get an error about No known ancestor relationship between git versions then you probably installed clj-new :as new previously, so you will need to remove that first: clojure -Ttools remove :tool new. clj-new should be installed :as clj-new if you want to use both tools.

deps-new only supports :local/root and git-based coordinates, not Maven/Clojars coordinates. If you want an alternative that supports distributing your templates using Maven/Clojars look at clj-new but bear in mind I am no longer actively maintaining that.

Note: if you see instructions to use a template that look like clojure -A:new some-template :name whatever or clojure -Tnew some-template :name whatever, where some-template is not one of the built-in templates (app, lib, pom, scratch, template), those probably refer to clj-new rather than deps-new. Any templates other than the built-in ones are created and maintained by the community in repositories elsewhere, so please open issues or ask questions of the appropriate maintainer (not me).

The documentation here is structured as follows:

  • Motivation -- why does deps-new exist?
  • Create an Application -- how to create a basic application project, that can build an uberjar
  • Create a Library -- how to create a basic library project, that can build a JAR and deploy to Clojars
  • Create a Template -- how to create your own deps-new template project
  • Additional projects/files that deps-new can create (scratch, pom.xml)
  • More General Usage -- this includes links to additional documentation:
    • Project Names and Variables to see how the project name (:name) is used to derive the default values of all the built-in substitution variables
    • All the Options for the full list of command-line options available when invoking deps-new
    • Writing Templates for documentation on how to write your own templates

Followed by sections listing some community deps-new templates, integration with Emacs, some notes about the generated LICENSE file, and finally how to use deps-new with the Babashka CLI library.

Motivation

clj-new inherently carries along all of the baggage of lein new and boot new, including a modified chunk of Leiningen itself, as well as depending on Pomegranate for loading dependencies (so as to be compatible with Leiningen and Boot), and Stencil for the variable substitution in templates. The recently-released tools.build library, from the core Clojure team, provides all of the functionality needed to create new projects from templates, so deps-new aims to provide a wrapper around tools.build, some standard templates "out of the box", and machinery to allow you to easily write your own templates, mostly with no code needed at all.

The app and lib templates in deps-new are currently almost identical to those in clj-new, in terms of what they provide in generated projects, although they need no code: deps-new templates are primarily declarative, using a template.edn file to describe how parts of the template are copied into the target project folder.

You can get help on the available functions like this:

clojure -A:deps -Tnew help/doc

Create an Application

clojure -Tnew app :name myusername/mynewapp

Creates a directory mynewapp containing a new application project, with myusername as the "top" namespace and mynewapp as the main project namespace:

;; mynewapp/src/myusername/mynewapp.clj
(ns myusername.mynewapp
  (:gen-class))

(defn greet
  "Callable entry point to the application."
  [data]
  (println (str "Hello, " (or (:name data) "World") "!")))

(defn -main
  "I don't do a whole lot ... yet."
  [& args]
  (greet {:name (first args)}))

In this new project, you can run clojure -A:deps -T:build help/doc to see what tasks are available in build.clj. You can run the following in the freshly-generated project:

  • clojure -T:build test -- run the tests (they'll fail until you fix them!)
  • clojure -T:build ci -- run the tests and build the (AOT-compiled) uberjar

Consult the generated README.md file for additional details on how to run the source code, run the tests, and build and run the uberjar.

Create a Library

clojure -Tnew lib :name myusername/mycoollib

Creates a directory mycoollib containing a new library project, with myusername as the "top" namespace and mycoollib as the main project namespace under that.

If you want to generate the project into a different directory than the project name, use the :target-dir option to specify a path to the directory that should be created:

clojure -Tnew lib :name myusername/mycoollib :target-dir projects/newlib

Creates a directory projects/newlib containing a new library project, with myusername as the "top" namespace and mycoollib as the main project namespace under that.

In this new project, you can run clojure -A:deps -T:build help/doc to see what tasks are available in build.clj. You can run the following in the freshly-generated project:

  • clojure -T:build test -- run the tests (they'll fail until you fix them!)
  • clojure -T:build ci -- run the tests and build the library jar

Consult the generated README.md file for additional details on how to run functions from the source code, run the tests, build the jar, install it locally or deploy it to Clojars.

Create a Template

clojure -Tnew template :name myusername/mytemplate

Creates a directory mytemplate containing a new template project, with myusername as the "top" namespace and mytemplate as the main project namespace under that. The generated template project will work as a template that produces a library project, but you can change it to produce whatever you want.

If you want to generate the project into a different directory than the project name, use the :target-dir option to specify a path to the directory that should be created:

clojure -Tnew template :name myusername/mytemplate :target-dir projects/newtemplate

Creates a directory projects/newtemplate containing a new library project, with myusername as the "top" namespace and mytemplate as the main project namespace under that.

In this new project, you can run clojure -A:deps -T:build help/doc to see what tasks are available in build.clj. You can run the following in the freshly-generated project:

  • clojure -T:build test -- run the tests (they'll fail until you fix them!)

Consult the generated README.md file for additional details on how to work with the newly-generated template project.

Create a Minimal "scratch" Project

If you just want a very minimal deps.edn project to experiment with:

clojure -Tnew scratch :name play

Creates a directory play containing an empty deps.edn file and src/scratch.clj with a simple exec function (you can invoke via clojure -X scratch/exec) and a simple -main function (you can invoke via clojure -M -m scratch). This is intended to be a minimal "playground" to get started with deps.edn and the CLI.

If you want the scratch.clj file to have a different name, you can override the default with :scratch:

clojure -Tnew scratch :name play :scratch ground

The created file will be src/ground.clj in the play folder. :scratch can be a path:

clojure -Tnew scratch :name play :scratch play/ground

The created file will be src/play/ground.clj in the play folder.

Create a Fully-Fleshed pom.xml

clojure -Tnew pom :name com.acme/cool-lib :target-dir .

Creates a pom.xml file in the current directory (overwriting any existing file!) that has all the fields needed to publish a project to Clojars and have cljdoc.org generate the documentation, e.g.,

  <groupId>com.acme</groupId>
  <artifactId>cool-lib</artifactId>
  <version>0.1.0-SNAPSHOT</version>
  <name>com.acme/cool-lib</name>
  <description>FIXME: my new org.corfield.new/pom project.</description>
  <url>https://github.com/com.acme/cool-lib</url>
  <licenses>
    <license>
      <name>Eclipse Public License</name>
      <url>http://www.eclipse.org/legal/epl-v10.html</url>
    </license>
  </licenses>
...
  <scm>
    <url>https://github.com/acme/cool-lib</url>
    <connection>scm:git:https://github.com/acme/cool-lib.git</connection>
    <developerConnection>scm:git:ssh:[email protected]:acme/cool-lib.git</developerConnection>
    <tag>v0.1.0-SNAPSHOT</tag>
  </scm>

You should run clojure -X:deps mvn-pom to synchronize the <dependencies> from your deps.edn file.

More General Usage

Currently those are the only five built-in templates (app, lib, pom, scratch, and template).

More general usage:

clojure -A:somealias -Tnew create :template com.acme.project/cool-lib :name myusername/mynewproject

Looks for com/acme/project/cool_lib/template.edn on the classpath (based on the :somealias alias) and, if present, uses that template to create a project, in mynewproject. Instead of -A:somealias, you could use -Sdeps to specify the dependencies needed to make the template available:

clojure -Sdeps '{:deps {io.github.acme/templates COORDINATES}}' -Tnew create :template com.acme.project/cool-lib :name myusername/mynewproject

The COORDINATES could be something like {:local/root "/path/to/cool-lib"} for a template that exists on the local filesystem, or it could be based on :git/url/:git/sha etc for a template that exists in a git repository.

As of v0.7.0, if you are using Clojure 1.12 -- either as the default :deps in your deps.edn file or via an alias, such as -A:1.12 -- you can use a shorter syntax for the template dependency:

clojure -A:1.12 -Tnew create :template io.github.acme/templates%com.acme.project/cool-lib :name myusername/mynewproject

deps-new will infer a git dependency, as https://github.com/acme/templates, figure out the latest version on the default branch, check that out, and add it to the classpath, and then proceed to use com.acme.project/cool-lib as above. If you want to use a specific tag, you can use # to append that to the template specification, e.g., io.github.acme/templates%com.acme.project/cool-lib#v1.2.3. If the repo is structured such that the Clojure root is not the root of the repo itself, i.e., you would normally use :deps/root in the coordinates, you can specify that with an extra % in the template specification, after the repo and before the actual template name, e.g., io.github.acme/templates%lib%com.acme.project/cool-lib#v1.2.3. This would be equivalent to {:deps {io.github.acme/templates {:git/tag "v1.2.3" :deps/root "lib"}}} (which would not be legal without :git/sha as well for -Sdeps but deps-new will resolve the tag to a SHA for you).

If your template name matches the git "lib" name, you can omit the template from the specification, e.g., io.github.acme/cool-lib would be treated as both the implied git repo and also the template name, as if you had specified: io.github.acme/cool-lib%io.github.acme/cool-lib.

The examples above using -A:1.12 assume an alias like this in your deps.edn file:

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

Note: if you are on Windows, read Quoting keys and values in the official Deps and CLI Reference documentation to understand how the above command needs to look on Powershell. Or take a look at the Babashka CLI library support.

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.

As of v0.6.0, :src-dirs can be used to specify a list of directories to search for templates, in addition to the classpath. Those directories are searched in order, and take priority over the classpath. This allows you to have templates in a directory structure that is outside the classpath, and also makes it easier to use deps-new as a library.

See Project Names and Variables to see how the project name (:name) is used to derive the default values of all the built-in substitution variables. See All the Options for the full list of command-line options available when invoking deps-new. See Writing Templates for documentation on how to write your own templates.

Practical.li also has an excellent guide to writing deps-new templates.

Templates

The following templates are available externally. If you have written a template and would like to add it to the list, please make a PR.

Emacs Integration

An emacs package is available which provides a Magit-style interface to clj-new and deps-new. It includes some community templates and welcomes for recommendations for more.

The Generated LICENSE File

The generated projects (from the built-in app, lib, and template templates) all contain a LICENSE file which is the Eclipse Public License (version 1.0) and that is also mentioned in the generated README.md files. This is a tradition that started with Leiningen's lein new and carried over into boot new and now clj-new. The idea is that it's better to ensure any open source projects created have a valid license of some sort, as a starting point, and historically most Clojure projects use the EPLv1.0 because Clojure itself and the Contrib libraries have all used this license for a long time.

You are not required to open source your generated project! Just because the projects are generated with an open source LICENSE file and have a License section in their README.md files does not mean you need to keep that license in place, if you do not want your project to be open source.

You are not required to use EPLv1.0 for your project! If you prefer a different license, use it! Replace the LICENSE file and update the README.md file to reflect your personal preference in licensing (I have tended to use the Apache License 2.0 in most of my open source projects, prior to working with Clojure, but see Prefer the MIT License for an alternative viewpoint from the folks who wrote XTDB).

Note: if you incorporate any source code from other people's open source projects, be aware of the legal implications and that you must respect whatever license they have used for that code (which may require you to release your enhancements under the same license and will, most likely, require you to include their copyright notices, etc). Do not copy other people's code without attribution!

Babashka CLI

The babashka CLI library allows you to call an -X (exec) function in a more Unixy way, without writing EDN on the command line. If you are dealing with quoting issues in your shell, this could be a viable alternative:

:new {:deps {org.babashka/cli {:mvn/version "0.2.15"}
             io.github.seancorfield/deps-new {:git/tag "v0.7.1"
                                              :git/sha "c1e42aa"}}
      :ns-default org.corfield.new
      :exec-args {} ;; insert default arguments here
      :main-opts ["-m" "babashka.cli.exec"]}

This allows you to call deps-new on the command line as:

$ clj -M:new app --name foo/bar --overwrite delete

License

Copyright © 2021-2024 Sean Corfield

Distributed under the Eclipse Public License version 1.0.

deps-new's People

Contributors

borkdude avatar burinc avatar dpassen avatar jpe90 avatar kingmob avatar mynomoto avatar rafaeldelboni avatar seancorfield avatar walterl avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

deps-new's Issues

[Feature request ] - Derivative templates

Creating an entire template to get a few small changes on top of an existing template seems like unreasonable overhead, and following our discussion on Clojurians Slack, I came to the idea of derivative templates - a derivation is defined in terms of the "delta" over an existing template.
This also allows creating a sequence of derivation, each a function of the last.
Derivations need to account for the transformation fns and file changes.

  • transformation fns: chain all of them
  • file changes:
    • if a file with the same name exists, override it
    • if a .diff or .patch file exists, apply it

And that's how you make "epochal" functional templates.
WDYT?

Make deps-new more usable as a library

@behrica Carsten Behring asked:

  • is there a way to use deps-new as a library, not as a cli tool ?
    My use case ist to re-use the logic which "copies" root folder to target and does substitutions including use of template-fn from my own code.

I do not want to create a full new clojure project but to "add" folders to an existing directory and re-use the template-fn logic.

Slack Message

I tried to call the org.corfield.new/create fn and it does work, but it makes the assumption that root dir and template.edn are on classpath, correct ?

This would not be the case in my scenario, they would exist at "local dir/file"

the find-root fn makes this assumption, at least.

Me:

  • If create took an option that specified additional directories to search, it could pass that to find-root as additions to the classpath roots... would that work for you?

Document how namespace mapping and :target-dir work

athomasoriginal on Slack:

Request: flexible approach to naming the app/lib folder/project/files/ns. Right now, clj-new does company/project and i’ve felt that how that manifests into a folder/file/ns structure is not as flexible or intuitive as I might like.

Is there a declarative way to not apply substitutions during file copying?

I was working on developing a deps-new template for cryogen. That project contains several files that already contain {{something}} in them (since they are selmer templates) that should not be substituted during copying to a new project. For example, the current cryogen lein template generates files that contain {{name}}.

I guess I could use :data-fn but was looking for something more declarative, if available.

Thanks.

add sr.ht and Codeberg as SCM domains

What are your thoughts on adding https://git.sr.ht/ and https://codeberg.org/ as SCM domains? Of course it's easy enough to add them manually, but since these two seem like some of the bigger open source hosting domains it could be a nice convenience to have them included.

edit: PR attached since it's a minor change, though I'm not quite sure if I have the git.sr.ht domain added correctly -- apologies as this is one of the few PRs I've ever done.

[Feature request] Add ability to use conditions in templates

In my opinion, an ability to make templates a slightly dynamic will help visualize possible changes in templates based on template variables. I'm thinking about something similar to Selmers' {{ if some-var = "value" }}...{{ endif }}. I don't propose any other tags but if probably would be helpful.

An example for the case when conditions could be useful. Let's suppose we have basic deps.edn file template and we want to add to it different features that have its own dependencies. So for instance, we would like to give our users optional ability to add database config to project created from a template. Now basic deps.edn could look like this:

{:deps {org.clojure/clojure {:mvn/version "1.11.1"}{{extra-deps}}}
 ...}

And then, if we pass arg, for example, :db true to generating command, we add deps internally and get result:

 {:deps {org.clojure/clojure {:mvn/version "1.11.1"}
         com.github.seancorfield/next.jdbc {:mvn/version "1.2.780"}
         org.postgresql/postgresql {:mvn/version "42.4.0"}}
  ...}

But if we had had built-in if condition in template, we could have written the same template a slightly more explicit:

 {:deps {org.clojure/clojure {:mvn/version "1.11.1"}
         {{ if db }}
         com.github.seancorfield/next.jdbc {:mvn/version "1.2.780"}
         org.postgresql/postgresql {:mvn/version "42.4.0"}}
         {{ endif }}
  ...}

Rethink :overwrite option

Russell Mull on Slack:

My wish may be impossible: a way to change my mind about template options after the fact. Consider Luminus: (yes, it's a lein template) There are a bunch of choices that you have to make up front, but have no way to re-visit or re-examine later. We should be able to instantiate the basic thing, and then later add the "reagent" option (or whatever). I could imagine that this would only work if you haven't changed too much of the template, already.

Rick Moynahan replied:

I think modifying / integrating existing code whether it came from a template or not is going to be very awkward.
However I do think if it’s not already supported a way of overlaying new files into the same project may be worth while.
e.g. imagine you clj-new a minimal clojure project then later decide to add in your companies default circle ci template. Providing the file additions don’t intersect with code in the repo already that would be ok.

My response:

That's good feedback. I currently have it written to not overwrite an existing project, unless you say :overwrite true but, right now, that deletes any existing target directory first. I'll create an issue to rethink that.

Provide a way to reuse the library coordinate for the template, without incurring deps

It might be useful to allow authors to reuse the coordinate of the main project for the template. Highlighting my own project there are two coordinates currently: io.dominic/wedge and io.dominic/wedge-template. It would be nice if the coordinate was just the library coordinate though (this is why {clj,boot,lein}-new do that awful /lein-template business, it gives you a pretty name which matches your project).

One inspiration for this is the :deps/prep-lib which allows you to specify which alias to use for "building". By using an alias for resolution, you could specify additional dependencies (e.g. mustache) which are needed when generating the template.

I'm not sure how much I actually want this. I don't feel strongly about having 2 coordinates.

Executable file permission is lost when app is created from template

I am creating a new template for my projects. The root folder has a script at path root/bin/kaocha with executable permissions.

When creating a dummy application, the script is created correctly. However it doesn't have the executable permission on it. All this is on WSL2 Linux.

Slack conversation - https://clojurians.slack.com/archives/C019ZQSPYG6/p1638439206035200

Link to repo for my template - https://github.com/amithgeorge/deps-new-app-template

Command to create app from template -

clojure -Sdeps '{:deps {com.amithgeorge/app-template {:git/sha "0db7f25ae1f17f5ee739704389853531ebc7ad6b", :git/url "https://github.com/amithgeorge/deps-new-app-template.git"}}}' -Tnew create :template com.amithgeorge/app-template :name com.example/test-app

Other debugging steps

clojure.tools.build.api/copy-dir is able to properly copy files and retain the executable permission. Repo - https://github.com/amithgeorge/tools-build-executable-file-copy-bug

It should not be necessary to use -Sdeps to reference a third-party template

Currently, you must specify using -Sdeps a literal chunk of dependencies so that deps-new can find your template.edn (based on the :template from the command line).

As a user, I would expect deps-new to be able to work directly from the template, expecting the template to match a Maven artifact. deps-new should be able to build a basis directly from that (after somehow figuring out the correct :mvn/version) and build a classpath from that basis.

Some of template seems too old to use

As title,

for example, some template like electron-app still use clojure -A in readme, which is been deprecated and not suggest by clojure official,

also, some template can't build now,
I use electron in my Macs Monterey 12.5
when I follow the readme to start dev environment,
it show a blank electron window.

does anyone maintain the templates anywhere?

Document :data-fn and :template-fn

Currently, the new templates have no code associated with them. Some templates might want some "computation" done. The template.edn file could have an optional key naming a function to require/invoke.

That function should be passed the hash map of data that deps-new will use to create the template, and the result of that function should be merged into the data (so it can just return new keys to add/replace if it wants).

It would probably be helpful for such tools to be passed the directory from which the template is being read?

Better support for "subprojects" within a project

Make it easier to support "non-traditional" project structures, such as a monorepo where the top-level perhaps contains build-related stuff and the actual "project" is in one or more subfolders.

Ah ok. For example, I structure my projects where the top-level directory is "what runs on my laptop," e.g. what's required to create and run the container and then "what runs inside the container" is in a sub-directory, like https://gitlab.com/tvaughan/kibit-runner. For larger projects involving multiple containers, as well as limiting the host mounted volume to each project's sub-directory instead of the top-level directory (see the top-level Makefile) this layout has been really helpful (edited)

The :target-dir option helps with this since you can specify a nested folder to be created as the target directory and, once #1 is implemented, you would be able to overlay multiple templates into a single monorepo-style structure. This can be explained in the documentation.

Failed to install, Unreadable arg: "{:git/tag"

I get the above error when trying to install the tool with.

clojure -Ttools install io.github.seancorfield/deps-new '{:git/tag "v0.4.9"}' :as new

  • Fedora Linux 36 (Inside a podman container with the same os as the host)
  • Both Fish and Bash shell tried.
  • Clojure CLI version 1.11.1.1105

Suggestion: Simpler DX when using this tool with custom templates.

First of all thanks for your work on this, template tools are super useful even more when deep integrated with the current developer workflow.

But I found that using this tool with custom templates in the CLI a little bit verbose, for example:

clojure -Sdeps '{:deps {cc.delboni/helix-scratch {:git/url "https://github.com/rafaeldelboni/helix-scratch" :git/sha "8e4eb30" :git/tag "v0.1.1"}}}' -X:new :template cc.delboni/helix-scratch :name myusername/mycoolsite

Is quite a lot to type and I know that isn't case of everyday you will create a new project, but I really like when the command is something I can type by heart like was possible with clj-new and maven third-parties templates:

clojure -Tclj-new create :template cc.delboni/helix-scratch :name myusername/mycoolsite

I understand the fact of not using maven in this project, so I went ahead and searched for another similar tools that mainly use git as source of the third-party templates and I found cargo-generate.

The most interesting aspect of this tool is its CLI usage, here some examples:

cargo generate username-on-github/mytemplate
# is the same as 
cargo generate gh:username-on-github/mytemplate
# is the same as 
cargo generate --git https://github.com/username-on-github/mytemplate.git

If you have your templates not GitHub then you can leverage the lazy abbreviation prefixes:

# for gitlab.com
cargo generate gl:username-on-gitlab/mytemplate
# or for bitbucket.org
cargo generate bb:username-on-bitbucket/mytemplate
# or for github.com 
cargo generate gh:username-on-github/mytemplate

Do you think this project could fit a similar CLI "api"? I would be keen to contribute with a PR if so, we could discuss some new usage ways like for example:

clojure -X:new :template cc.delboni/helix-scratch@gh :name myusername/mycoolsite
# or
clojure -X:new :gh cc.delboni/helix-scratch :name myusername/mycoolsite

One thing cargo-generate lacks is the option to set the version or the commit hash you want from the template you will be using, but we could think some extra args for that as well.

WDYT?

how to build ci with aliases

the deps.edn file:

{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.11.1"}}
 :aliases
 {:run-m {:main-opts ["-m" "etl.core"]}
  :run-x {:ns-default etl.core
          :exec-fn greet
          :exec-args {:name "Clojure"}}
  :build {:deps {io.github.seancorfield/build-clj
                 {:git/tag "v0.6.3" :git/sha "9b8e09b"
                  ;; since we're building an app uberjar, we do not
                  ;; need deps-deploy for clojars.org deployment:
                  :deps/root "slim"}}
          :ns-default build}
  :dev {:extra-deps {org.apache.spark/spark-core_2.11 {:mvn/version "2.3.4"}
                     org.apache.spark/spark-sql_2.11 {:mvn/version "2.3.4"}
                     org.apache.spark/spark-hive_2.11 {:mvn/version "2.3.4"}}
        :main-opts ["-m" "etl.core"]}
  :test {:extra-paths ["test"]
         :extra-deps {org.clojure/test.check {:mvn/version "1.1.1"}
                      io.github.cognitect-labs/test-runner
                      {:git/tag "v0.5.1" :git/sha "dfb30dd"}}}}}

how can i build uber with :dev aliases
i have try clj -T:build ci or clj -T:build:dev ci but fail with ClassNotFoundException

Running basic tests for a new app

Creating an app with the command:

$ clojure -Tnew app :name myusername/mynewapp

Seems to produce all the boilerplate and directories that are needed to get going but there's little guidance on executing the basic (failing) tests that are generated at the same time which is a problem for newcomers to the concept of test-runners. Reading around suggests that the command

$ cd mynewapp
$ clj -X:test

should be sufficient to kick things off but this produces the error message:

"No function found on command line or in :exec-fn"

What's the right way to execute the tests? Could something be added to the README?

Project not published to maven repositories

Right now the project is not published to maven repositories.

The only way to define dependency on deps-new is using :git/tags and :git/sha

Please consider adding to maven so that dependency can be defined using :mvn/version

[template] .tmpl files remain after creating a new project with template template

In a project created with the template template, i noticed several *.tmpl files in the root of the new project.

My assumption is these are remnants from the original template template and should not have appeared in the newly created project

├── build.clj
├── build.tmpl
├── CHANGELOG.md
├── deps.edn
├── deps.tmpl
├── doc
│   └── intro.md
├── pom.xml
├── README.md
├── resources
...
├── template.tmpl

Also noted that resources/.keep file is in the new project, which I assume is not required for a template project, as the resources directory will contain other files and does not need a placeholder file. This is a very minor issue though.

The command used to create the new project:

clojure -T:project/create :template template :name practicalli.template/service :target-dir clojure-cli-project-templates  

For reference, the alias used in the Clojure command is

  :project/create
  {:replace-deps {io.github.seancorfield/deps-new {:git/tag "v0.5.0" :git/sha "48bf01e"}}
   :exec-fn      org.corfield.new/create
   :exec-args    {:template app :name practicalli/playground}}

Support loading template files through multiple deps

I ran into an issue when trying to add deps-new to Kit. The idea is to share the same base files so we can support both deps-new and clj-new with minimal duplication. I started off planning to do this:

  • base-template: shared template files
  • deps-template: new deps-new implementation
  • lein-template: existing clj-new implementation

In this scenario the base-template would be shared by both deps-template and lein-template. The deps-template would just have a template.edn file and the processing functions to implement the logic on top of the base files.

However, when I tried to implement this, I ran into a limitation with deps-new: it only supports one root directory per template, so any dependencies were not being included as part of the template, even with the same resource path (resources/io/github/kit_clj/kit). For now I'm just going to have lein-template depend directly on deps-template since clj-new doesn't have the same restriction.

Would it make sense to support multiple roots for a single template? Is there a better workaround I'm not thinking of? Maybe this is too specific to Kit and not worth supporting in general?

(This is kind of related to #27 but I think this problem is more narrow in scope. For splitting templates into multiple libraries, simply merging the roots together could be an option without having composition of templates.)

Add template template

This is going to require a way to circumvent the substitution machinery for file contents (or at least some file contents?) so that template files can be copied as-is.

Probably the simplest approach is making the raw folder "special" in that it disables :replace for copy-dir or perhaps provides an alternative substitution syntax (such as <<foo>> perhaps instead of {{foo}}).

Offer more (some!) approaches for template testing?

Dominic Monroe on Slack:

An approach to testing, even just a few basic utilities to spin up a repl of some kind and run some functions, testing that they don't explode would be great. Right now I have a bash script that generates a few variants of the project and then I manually check that they do sensible things (like that (dev) works, or that a server starts)

Ignore `.clj-kondo/.cache`

The default .gitignore file already ignores some tool-specific files, like clojure-lsp's .lsp/sqlite.db, but .clj-kondo/.cache is currently not in the default ignore list. I suggest that it be added.

Installation Problem in Windows

Using the most current version : https://github.com/clojure/tools.deps.alpha/wiki/clj-on-Windows

When I execute the command

"clojure -Ttools install io.github.seancorfield/deps-new '{:git/tag "v0.4.9"}' :as new" in Windows 10 x64

I get the following error.

Execution error (ExceptionInfo) at clojure.tools.deps.alpha.extensions.git/coord-err (git.clj:45).
Library io.github.seancorfield/deps-new has invalid tag: v0.4.9

=== Full Report ===

{:clojure.main/message
 "Execution error (ExceptionInfo) at clojure.tools.deps.alpha.extensions.git/coord-err (git.clj:45).\r\nLibrary io.github.seancorfield/deps-new has invalid tag: v0.4.9\r\n",
 :clojure.main/triage
 {:clojure.error/class clojure.lang.ExceptionInfo,
  :clojure.error/line 45,
  :clojure.error/cause
  "Library io.github.seancorfield/deps-new has invalid tag: v0.4.9",
  :clojure.error/symbol
  clojure.tools.deps.alpha.extensions.git/coord-err,
  :clojure.error/source "git.clj",
  :clojure.error/phase :execution},
 :clojure.main/trace
 {:via
  [{:type clojure.lang.ExceptionInfo,
    :message
    "Library io.github.seancorfield/deps-new has invalid tag: v0.4.9",
    :data
    {:lib io.github.seancorfield/deps-new,
     :coord
     {:git/tag v0.4.9,
      :git/sha "ba30a76af8b42a45f8498a168bf89518a794fce5"}},
    :at
    [clojure.tools.deps.alpha.extensions.git$coord_err
     invokeStatic
     "git.clj"
     45]}],
  :trace
  [[clojure.tools.deps.alpha.extensions.git$coord_err
    invokeStatic
    "git.clj"
    45]
   [clojure.tools.deps.alpha.extensions.git$coord_err
    invoke
    "git.clj"
    43]
   [clojure.tools.deps.alpha.extensions.git$eval1234$fn__1236
    invoke
    "git.clj"
    66]
   [clojure.lang.MultiFn invoke "MultiFn.java" 239]
   [clojure.tools.tools.api$install invokeStatic "api.clj" 45]
   [clojure.tools.tools.api$install invoke "api.clj" 20]
   [clojure.lang.AFn applyToHelper "AFn.java" 154]
   [clojure.lang.AFn applyTo "AFn.java" 144]
   [clojure.lang.Var applyTo "Var.java" 705]
   [clojure.core$apply invokeStatic "core.clj" 667]
   [clojure.core$apply invoke "core.clj" 662]
   [clojure.run.exec$exec invokeStatic "exec.clj" 48]
   [clojure.run.exec$exec doInvoke "exec.clj" 39]
   [clojure.lang.RestFn invoke "RestFn.java" 423]
   [clojure.run.exec$_main$fn__205 invoke "exec.clj" 178]
   [clojure.run.exec$_main invokeStatic "exec.clj" 174]
   [clojure.run.exec$_main doInvoke "exec.clj" 139]
   [clojure.lang.RestFn applyTo "RestFn.java" 137]
   [clojure.lang.Var applyTo "Var.java" 705]
   [clojure.core$apply invokeStatic "core.clj" 667]
   [clojure.main$main_opt invokeStatic "main.clj" 514]
   [clojure.main$main_opt invoke "main.clj" 510]
   [clojure.main$main invokeStatic "main.clj" 664]
   [clojure.main$main doInvoke "main.clj" 616]
   [clojure.lang.RestFn applyTo "RestFn.java" 137]
   [clojure.lang.Var applyTo "Var.java" 705]
   [clojure.main main "main.java" 40]],
  :cause
  "Library io.github.seancorfield/deps-new has invalid tag: v0.4.9",
  :data
  {:lib io.github.seancorfield/deps-new,
   :coord
   {:git/tag v0.4.9,
    :git/sha "ba30a76af8b42a45f8498a168bf89518a794fce5"}}}}

Consider moving pom.xml to template folder

Similar to how I manage my own OSS projects' pom.xml files -- so tooling doesn't think see a top-level pom.xml and assume it is definitive.

Need to add :src-pom to the options map, and add a note to the README about why this is done.

Consider not using .clj for extension of template source files

These files are not valid Clojure (and probably are not valid EDN either).

This should help avoid problems with tooling downstream, for anything that might assume it can load .clj files as Clojure code.

Probably ought to update the docs too, so folks building their own templates do not trip over this.

Add base, component, project, and workspace templates

This is mostly an example of flexibility that would allow a Polylith workspace to be created and then for pieces to be added to it. Not intended as a replacement for the poly tool but as a set of templates to show how layers can be added to an existing project. Should leverage the data-processing function to manipulate :target-dir and maybe other things.

We should probably port across the current Polylith template as well as these individual templates.

Verify template documentation

It has:

;; template.edn
{:transform [["resources" "resources/{{top/file}}"]]}

But I think that isn't actually legal because the tuple requires three or four elements.

Also need to document the open/close tuple for templates.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.