Fork me on GitHub
Mark Wardle07:05:00

Hi all, a dependency of a dependency of a dependency of my code redefines a new clojure 1.11 core function. It is problematic to have these warnings on application startup when used as a command-line tool, particularly as they are surprising when my code is run as an uberjar by third-parties, although I have no difficulty at all in ignoring them for server applications. Obviously, if this were my code, I could either rename or exclude them from that specific namespace. Is there a way of suppressing these warnings? Thank you


I think the best long term solution is to add a PR to those libs with :refer-clojure :exclude [parse-long] . Note that this solution works for older clojure versions without parse-long too

💯 4
Mark Wardle15:05:23

Thanks both. It does feel a bit wrong to get a warning relating to a third-party library, and of course of no actual consequence to me unless I'm directly using the offending function [and then I'd be explicit because it's in someone else's namespace so it shouldn't matter then either]. It feels as it should be possible to customise this in some way - because additive change to clojure.core causes these warnings which almost never matter to me as a library user.


> It feels as it should be possible to customise this in some way That's why that issue has been filed. ;)

Mark Wardle15:05:38

Yes - I started reading the issues log after posting that!

Mark Wardle15:05:07

I should probably read jira before posting to slack 🙂


TBF, you did get 2 comments that aren't in that Jira ticket, so the outcome was worth it.

👍 1
Mark Wardle15:05:43

Yes and to be fair most libraries have updated since clj 1.11 so this isn't as much of an issue as it was. But… :)


@U013CFKNP2R This happens with almost every new release of Clojure as it adds new core functions. In an ideal world, all library maintainers would test their code against Clojure master or at least against each prerelease as it appears. I test against master as a matter of course on all my libraries.

👍 1

At work, we always at least test against each new prerelease as it appears (and we often go to production with each new prerelease) -- which means I tend to run into this issue a lot with library maintainers who don't test against master... and I go to every library's repo and open an issue. Some maintainers fix them very quickly. Some don't. Clojure 1.11 Alpha 3 caused me to open issues against three libraries. Alpha 4 caused me to open issues against three different libraries. All six of those issues were fixed by the time shortly after Clojure 1.11 was released, at the latest.


But we as a community should get better about testing things against prereleases, not just waiting until the "gold" release drops.

Mark Wardle06:05:54

Thanks Sean. I can't disagree but I think the idea on JIRA of a similar flag to ‘warn on reflection’ might help. I know it isn't a breaking change, but somehow it feels as if it's testing the policy of additive change only, given one gets a warning from, by definition, additive change in core. There's something about the difference between authoring and consuming a library, as if I'm explicitly using a function in someone else's namespace then it is of doubtful benefit for me to get a warning. Perhaps there could be an override to set the namespaces in which this check should run, or perhaps, should not run.

Alexander Kouznetsov21:05:37

How can I get access to Whenever I’m trying to login, I’m getting the following message: Try a different account … <email> doesn’t have access to Jira on

Alex Miller (Clojure team)22:05:50

we reserve accounts on jira for those providing patches, otherwise we prefer that you log issues or comment on the equivalent issue on

🙏 1

One thing I have been missing is being able to watch tickets but yeah, I understand why you're doing it