Would there be interest in moving clj-http-lite into clj-commons? @vemv has done a lot of work to polish the project in terms of tests / CI and making it GraalVM compatible. Thereβs an upcoming release (maybe 1.0) and if people think this would make sense in clj-commons that might be a nice thing to combine it with. If not also totally fine π https://github.com/martinklepsch/clj-http-lite
I'm also maintaining a fork of this here: https://github.com/babashka/clj-http-lite I cut out slingshot to make it even more lite and compatible with bb (although that may no longer be needed since recent version of bb can run slingshot too, but this still will incur some startup time penalty). Afaik the code was already GraalVM-compatible. Perhaps we can join efforts into clj-commons, I would be fine with joining efforts if compatibility with bb could be included as an explicit goal there. Else I'll have to keep maintaining this fork to keep fulfilling that goal.
Yes my first goal was removing slingshot (compatibly) so we have it easy there I also saw a javax.xml.bind.DatatypeConverter change in your fork, I don't have an opinion there, simply I'd like to learn about the rationale/tradeoffs overall clj-http-lite has "bounced" from fork to fork over the years, would be nice to settle :)
> javax.xml.bind.DatatypeConverter change in your fork This can be safely done since Clojure no longer supports Java 1.7
I'm surprised that code path even works in graalvm native-image
@vemv I think bb doesn't support this (yet): https://github.com/martinklepsch/clj-http-lite/commit/f549627b7b9bdb8739e3b5592e72ffe091b7c51f but that functionality (the self signed SSL thing) can be made optional using a macro or reader conditional depending on whether the SSL classes are available or not
+ slingshot removed, add bb to tests and that's it. If all parties agree on this, I think we can have one unified repo, but I would be fine maintaining the fork as well if it's too much hassle.
Sounds good to me! no issue in having reader conditionals and an expanded CI And yes more hands/eyes better
Iβd be happy for it to move to clj-commons, another alternative would be a separate org for clj-http-lite. Having two or three forks actively maintained seems wasteful.
an org seems a bit too much for just one repo
I think clj-commons is the perfect place for this
Then Iβm all for it. I guess itβs just a matter of transferring? Iβm currently on vacation, but will of course help if anything is needed.
I noticed today that clj-commons has only 4 members in the organisation. Are there more members that simply haven't allowed their membership to be visible? I guess some repos will have collaborators added, but it strikes me that maybe there should be more people as actual organisation members too. What do people think? Is it time to attempt to recruit a few more? People that have proven to be long-standing community contributors I suppose.
@joelittlejohn There's a difference between administrative members and contributors. The org only has the admin folks. The projects will have individual contributors.
See https://github.com/clj-commons/rewrite-clj/graphs/contributors for example.
A contributor is anyone that has ever had a PR merged (they will show in that graph), but yes I assume that individual repos have collaborators added. Do you feel comfortably that 4 people is enough admin folks for clj-commons itself? Seems like you could easily find yourself with only one or two people 'actively' admin'ing π
@joelittlejohn I see about 7 owners (admins, I think) but not all of them are public
(and there are 21 members overall in the clj-commons org, now that I actually go and look -- I'm a bit surprised so few people have their membership public...)