Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 0.4.0? #63

Closed
danielcompton opened this issue Oct 17, 2022 · 6 comments
Closed

Release 0.4.0? #63

danielcompton opened this issue Oct 17, 2022 · 6 comments

Comments

@danielcompton
Copy link
Member

What do you think about releasing 0.4.0 now with the namespace duplications? I'm working on some code with Java modules and this is one of the blockers.

I can probably do the release but wanted to check if it's ok.

@KingMob
Copy link
Collaborator

KingMob commented Oct 18, 2022

Ahh, that was back in July, wasn't it? OK, let me cut a release.

@KingMob
Copy link
Collaborator

KingMob commented Oct 18, 2022

Waitaminit, the namespace duplications have been available since 0.3.0. Are you using the old pre-org.clj-commons group coordinate? Other than some very minor doc changes, there's nothing that's not deployed already. ???

@KingMob
Copy link
Collaborator

KingMob commented Oct 21, 2022

@danielcompton Any updates?

@p-himik
Copy link

p-himik commented Dec 21, 2022

I'd love to see the duplications being removed actually. Just spend half a day debugging an issue where in the end it turned out that one of my dependencies required byte-streams while the other required clj-commons.byte-streams, thus making the conversions atom incompatible.

Getting rid of the duplications will make it into an error that should be obvious on how to fix it.

Alternatively, one of the duplicated namespaces could simply defer all of its functionality to the other namespace. Or at least all the state.

@KingMob
Copy link
Collaborator

KingMob commented Dec 22, 2022

From #aleph Slack:

Sorry you had to go through that.

We can't really remove the duplicate namespaces, but we can make one import the vars from the other, which should prevent this issue in the future.

Fundamentally, single-segment namespaces are problematic, and are discouraged for good reason these days. We know they interfere with Graal, and there's certainly more lurking time bombs, because they violate the widespread assumption that a class will be in a package.

@KingMob
Copy link
Collaborator

KingMob commented Jan 2, 2023

Shouldn't be any lingering ns duplication issues as of 0.3.2.

@danielcompton @p-himik Feel free to reopen if you have any concerns or issues.

@KingMob KingMob closed this as completed Jan 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants