Suppose I have a (leiningen) project tree created by git clone. This may be a subset of a project created via lein new template, which is perfectly legitimate. There is a --force option to roll a lein project over a suitable source tree already in place -- or so I presume. I tried it, something like this:
$ lein new app alfa --force
It replaced all the source files with the template stubs. What am I getting wrong?
The seminal discussion: issue #1467
You're not getting anything wrong here, this is the way the force option works. If your project already contains some subset of files and folders for a leiningen project, then they will be overwritten if they already exist in the project directory. This seems like conventional behavior considering the task that is being run is called "new." It's operating under the assumption that this is indeed a new project, but with a directory already created.
Related
I have multiple, separate leiningen projects that ostensibly could depend on one-another.
Example:
~/projects/mywebapp (my own project)
~/projects/noir (a clone of the github repo)
~/projects/clojureql (a clone of the github repo)
I want to have them all compiled into the same JVM at the same time. I would like to run the git repos bleeding edge (pulling new commits/making my own commits) and not have to run lein jar or lein deps and certainly not have to restart the VM if I change any of the projects.
Here's a use case:
After running lein swank, from within emacs, I connect to the repl and compile a file from mywebapp (with C-c-k), which requires a file from noir. It finds the version of the file in my projects directory. Later, I open that file, edit it, and compile it (with C-c-k).
Note that I'm not asking for auto-compiling when I do git pull. I just don't want to have to restart the JVM or do lengthy jar compiling processes.
Is this possible in leiningen? How can I set this up?
Does this question from the Lein FAQ help?
Q: I want to hack two projects in parallel, but it's annoying to switch between them.
A: Use a feature called checkout dependencies. If you create a directory called checkouts in your project root and symlink some other
project roots into it, Leiningen will allow you to hack on them in
parallel. That means changes in the dependency will be visible in the
main project without having to go through the whole
install/switch-projects/deps/restart-repl cycle. Note that this is not
a replacement for listing the project in :dependencies; it simply
supplements that for tighter change cycles.
If you're already using swank, you don't need lein checkout dependencies. You can just C-c C-k your project (which will load the jarred versions of noir/whatever), and then browse to your local version of noir and C-c C-k that as well. Swank happily sends all the code to your repl, and the jvm never need know that it came from a different place!
I can only recommend this for smallish changes though, because I think if you compile noir.core, which depends on (say) noir.internal, clojure will load the jarred version of noir.internal even while you compile the local version of noir.core. Even so, it's a handy trick in general.
Should I create a local repository to change the dependencies of a dependency in my project?
I have a clojure project that is using docjure. docjure contains a dependency on poi 3.6.
Because of a bug in generated Excel files I am reading, I have a local version of poi 3.8 that I hacked to workaround the bug.
It's easy enough to stick my poi 3.8 jars into my projects lib/ directory so that my project will run ok at the repl.
But, lein deps (or jar and uberjar) happily cleans the lib/ directory and reinstalls the 3.6 versions of poi, breaking my build.
I think the probable solution is two-fold:
1 - put my hacked poi 3.8 into a local repository
2 - create my own local copy of docjure and update it's dependencies to point to that local repository.
I am looking for confirmation that this is the "right thing" to do in this case or someone to point out that it is much easier to just do something else.
It is worth reading Leiningen's Repeatability wiki page if you haven't already. To quote part of it:
If the code is public, you should open a bug report with upstream to get them to publish it in a public repository like Clojars, Sonatype, or Maven Central, depending on the project. If they are resistant or too slow it's always possible to publish "Clojars forks"; see lein help deploying for further details there.
The ultimate solution is to try and get your changes pushed upstream. Then you can depend on the version you need, and I think Leiningen will prefer that version if it's higher than the transitive version.
Another option might be to include your jar in a safe (checked-in) directory. Then write a plugin that can hook into a built-in task and copy the jar to your lib directory for you. I really don't know if this will be successful, but it's worth looking into.
This is a wonderful project, but where to start?
I thought about making my own github fork for my own project. Or making a branch for each project "inside" of it.
Perhaps I do not really understand this social coding stuff yet -- but I am really feeling the allergy I have with "encapsulated" or "encapsulating" software frameworks and development environments.
Should one make a project inside of the source files, sitting next to the one.sample app? There are so many directories I do not know where to begin. Shouldn't most of the One project be sitting in clojars for us to use and spit out our own app templates, a bit like lein noir new <appname>?
Any and all insights appreciated, thank you!
In episode 3 of the Think Relevance podcast Brenton Ashworth says that at the moment there are three ways to take advantage of ClojureScript One (18min 38sec):
Copy the ClojureScript One project into your own project
Fork the ClojureScript One repo, delete the sample application, and build your own application inside the ClojureScript One project
Look at how CloureSript One handles dependencies, and then use the same approach to setup ClojureScript One as a dependency of your own project.
Sounds like the project team are aware of this being awkward at the moment, and they hope to be able to come up with a better story for this in the future.
To be honest with you.... I've had a ridiculous amount of trouble with clojurescript one. There's just too much code to work with and its good for a reference but not when beginners to clojurescript are just starting out.
The best way to get started with clojurescript is with chris granger's
https://github.com/ibdknox/cljs-template
start your project with:
lein new cljs-template <your project name>
cd <your project name>
lein run
That's it... just go into the src/client directory and start coding! basically, the template gives you a complete project that:
serves pages through ring
has cljs compilation on save so there is no need to muck around with lein cljsbuild
There is a 'clone' of clojurescript-one https://github.com/zcaudate/cljs-template-one made using cljs-template as a guide. It can be used as a project template:
lein new cljs-template-one <your project name>
cd <your project name>
chmod +x bootstrap.sh && ./bootstrap.sh
lein run
The project uses the twitter/bootstrap html template and can be viewed here:
http://cljs-bootstrapped.herokuapp.com/
ClojureScript One have a great wiki pages: https://github.com/brentonashworth/one/wiki. They seem very helpful.
Is there a typical workflow for hacking on Clojure libraries?
Say I have my application "Foo" which relies on a third-party library "Bar", which was obtained from a repository, and included in project Foo via lein deps.
Then, say I want to hack on library "Bar", so I clone it from github.
Now, I would like to hack on my local clone "Bar" while at the same time working on application "Foo" that depends on it. I would like all of the source files for "Bar" to open in Emacs along with all the source files in "Foo", using one instance of swank.
Is there an easy way to do this?
I want to alter my environment and not the project. Therefore I do not want to edit project.clj for "Foo" in order to accomplish this.
Does this require setting the classpath before starting up lein swank, or is there a better way?
Create a checkouts directory in your Foo project and create a symlink to your clone of the Bar project inside this directory.
To quote the Leiningen FAQ:
Q: I want to hack two projects in parallel, but it's annoying to switch between them.
A: If you create a directory called checkouts in your project root and symlink some other project roots into it, Leiningen will allow you to hack on them in parallel. That means changes in the dependency will be visible in the main project without having to go through the whole install/switch-projects/deps/restart-repl cycle, and the copy in checkouts will take precedence over the dependency declared in project.clj. Note that this is not a replacement for listing the project in :dependencies; it simply supplements that for convenience.
I have multiple, separate leiningen projects that ostensibly could depend on one-another.
Example:
~/projects/mywebapp (my own project)
~/projects/noir (a clone of the github repo)
~/projects/clojureql (a clone of the github repo)
I want to have them all compiled into the same JVM at the same time. I would like to run the git repos bleeding edge (pulling new commits/making my own commits) and not have to run lein jar or lein deps and certainly not have to restart the VM if I change any of the projects.
Here's a use case:
After running lein swank, from within emacs, I connect to the repl and compile a file from mywebapp (with C-c-k), which requires a file from noir. It finds the version of the file in my projects directory. Later, I open that file, edit it, and compile it (with C-c-k).
Note that I'm not asking for auto-compiling when I do git pull. I just don't want to have to restart the JVM or do lengthy jar compiling processes.
Is this possible in leiningen? How can I set this up?
Does this question from the Lein FAQ help?
Q: I want to hack two projects in parallel, but it's annoying to switch between them.
A: Use a feature called checkout dependencies. If you create a directory called checkouts in your project root and symlink some other
project roots into it, Leiningen will allow you to hack on them in
parallel. That means changes in the dependency will be visible in the
main project without having to go through the whole
install/switch-projects/deps/restart-repl cycle. Note that this is not
a replacement for listing the project in :dependencies; it simply
supplements that for tighter change cycles.
If you're already using swank, you don't need lein checkout dependencies. You can just C-c C-k your project (which will load the jarred versions of noir/whatever), and then browse to your local version of noir and C-c C-k that as well. Swank happily sends all the code to your repl, and the jvm never need know that it came from a different place!
I can only recommend this for smallish changes though, because I think if you compile noir.core, which depends on (say) noir.internal, clojure will load the jarred version of noir.internal even while you compile the local version of noir.core. Even so, it's a handy trick in general.