Patch Library From Clojars
Asked Answered
S

2

5

Say I'm using a library in a leiningen project, hosted on Clojars. And I run into a bug. I fork the project on Github, and fix the bug. Now what?

What's the most appropriate way to use my version of the library in my leiningen project?

P.S. I'm coming from the Ruby world, so I've obviously got Bundler on the mind...

Steffen answered 5/7, 2013 at 23:8 Comment(0)
Z
6

If you only want your modified version available locally, you can follow Arthur's process up to the "Test my program" step. This is fine if you're working on an application which you'll package together with its dependencies for deployment (with lein uberjar, say). You might also want to use Leiningen's checkouts feature to work on your main project and the modified library in parallel (documented in Leiningen's tutorial -- link to the version from the current 2.2.0 release).

If you want your modified version to be accessible in a public Maven repository, the accepted thing to do (indeed, encouraged for this specific use case and no other) is to release a version of the project with the original artefact id and a group id of org.clojars.{your-clojars-account-name}.

For example, if you wanted to release your own version of project foo with (defproject foo "upstream-version" ...) in its project.clj, you'd change its defproject form to (defproject org.clojars.kendallb/foo "your-version" ...) before release. Then you could depend on [org.clojars.kendallb/foo "your-version"] in your projects.

This way there won't be any conflict either with the original artefact id or any other forks.

As for getting your change merged upstream, Arthur's process is perfectly reasonable.

Zito answered 5/7, 2013 at 23:54 Comment(1)
I chose this answer because it included instructions for getting the patch all the way to production. Thanks!Steffen
E
6

my process:

  • Fork the project on github
  • Change the version from project-0.1.2-SNAPSHOT to project-0.1.2-arthur-SNAPSHOT in project.clj of the dependency
  • Fix the bug
  • Run "lein install" to add my fork to my local repo
  • cd to my project (the one using the dependency)
  • Change my porject.clj to depend on project-0.1.2-arthur-SNAPSHOT
  • Test my program
  • Submit a pull request to the maintainer of the dependency
  • Hop onto IRC and chat with the maintainer about the fix, and ask politely if my coding style matches their vision for the project. (this also helps expedite their merging)
  • Once they merge the fix remove the -arthur- from the name and test their SNAPSHOT branch
  • Beg and plead for them to release the fixed project so you can drop the SNAPSHOT dependency.
  • While you are waiting for the dependency to merge and release you can push your fork to clojars under your name and with a version string that identifies it as your fork (in my case I use -arthur-.

Tt's tempting to apply lots of "style fixes" to a project when you're just in there digging around to fix a bug. If you want to do this do try to work with the project maintainer because they are in it for the long haul and more emotionally invested in the code.

Equilibrist answered 5/7, 2013 at 23:31 Comment(0)
Z
6

If you only want your modified version available locally, you can follow Arthur's process up to the "Test my program" step. This is fine if you're working on an application which you'll package together with its dependencies for deployment (with lein uberjar, say). You might also want to use Leiningen's checkouts feature to work on your main project and the modified library in parallel (documented in Leiningen's tutorial -- link to the version from the current 2.2.0 release).

If you want your modified version to be accessible in a public Maven repository, the accepted thing to do (indeed, encouraged for this specific use case and no other) is to release a version of the project with the original artefact id and a group id of org.clojars.{your-clojars-account-name}.

For example, if you wanted to release your own version of project foo with (defproject foo "upstream-version" ...) in its project.clj, you'd change its defproject form to (defproject org.clojars.kendallb/foo "your-version" ...) before release. Then you could depend on [org.clojars.kendallb/foo "your-version"] in your projects.

This way there won't be any conflict either with the original artefact id or any other forks.

As for getting your change merged upstream, Arthur's process is perfectly reasonable.

Zito answered 5/7, 2013 at 23:54 Comment(1)
I chose this answer because it included instructions for getting the patch all the way to production. Thanks!Steffen

© 2022 - 2024 — McMap. All rights reserved.