workframers / garamond Goto Github PK

ERROR [garamond/main.clj:97] Current repository is dirty, will not create a tag. Please commit your changes and retry.
Created new git tag v0.1.1 from patch increment of v0.1.0

Got this when running the following in the cljdoc repo:

clj -Sdeps '{:dept {garamond {:mvn/version "RELEASE"}}}' -m garamond.main --artifact-id cljdoc --group-id cljdoc --scm-url "https://github.com/cljdoc/cljdoc" --tag patch

At that time the repository had some changes to tracked files (i.e. it was dirty).

Just wanted to drop a note that the newest version of tools.deps.alpha contains some api changes (moving towards getting out of alpha). So when you bump to tools.deps.alpha >= 0.9.745, you'll need to change your use of clojure.tools.deps.alpha.reader/slurp-deps - that is now in clojure.tools.deps.alpha.

Do you have plans to release a recent revision of garamond on Clojars? I'm having a problem that I believe could be fixed if garamond used a more recent version of tools.deps.alpha. You already committed the necessary bump to tools.deps.alpha, so I think all I'd need is a release of the current version of the code.

Thanks for your work on this surprisingly challenging part of a library author's life!

Hey @timgilbert, thanks for your work on Garamond!

I have two small questions/comments:

While it's nice to have the major, minor, patch semantics built in I was wondering if it would also be possible to specify the version string as a command line argument? I'd particularly like a versioning scheme that is like 0.0.123 where 123 is the number of commits in the current branch.

Note that garamond works on git tags; before you run it you should ensure you have at least one "annotated" git tag in your repo. You can create one via git tag --annotate -m "First version tag" v0.1.0.

There's this section in the README and I think it might be a little easy to miss for someone just skimming/looking at code. Maybe consider adding an emoji or boldening some of that to make it stand out more.

Unlike clj -Spom, Garamond's pom command does not create a build>sourceDirectory entry if :paths is not present in a deps.edn file, which will result in an error (Premature end of file) next time the pom is updated. (see applied-science/deps-library#1)

Looks like a bug in what this fn is doing: https://github.com/workframers/garamond/blob/master/src/garamond/pom.clj#L14

19-10-24 16:56:35 bianca2 ERROR [garamond.version:13] - Can't parse version string from '0.0': nil

I'm guessing it's because I don't have a patch segment, but I don't really want/need one.

I've added some special scope provided dependencies, and I want them to be left in and not removed by garamond.

With a :paths key like this I'm getting a message that most paths will be skipped:

 :paths ["src" "resources" "resources-compiled"
         "modules/shared-utils/src"
         "modules/shared-utils/resources"]

Skipping paths: resources resources-compiled modules/shared-utils/src modules/shared-utils/resources

resulting in the following pom.xml section:

  <build>
    <sourceDirectory>src</sourceDirectory>
  </build>

I think this message originates from clj -Spom but I also never understood why it would purposefully override what a user specified in the configuration and hoped that Garamond would handle this, i.e. ensure that all :paths are included in the POM.

🌱 It seems that this is mostly irrelevant when building a jar using pack.alpha or similar but it's still fairly confusing, especially if people aren't too familiar with Maven stuff.

Right now the --pom deps are generated just based on the current project's pom.xml, and not /usr/local/lib/clojure/deps.edn. This is probably incorrect and will probably not include the clojure dependency itself. We can probably use clojure.tools.deps.alpha.reader/clojure-env to get the proper location, although the extra JVM invocation stings.