Publish to crates.io
Closed this issue · 10 comments
Hey there.
I'd need this library for a project (Youtube TUI) but it's apparently not published to crates.io.
Would be great if this could be done.
(might also relate to #1 )
You can use it without having it published to crates.io, put this in your Cargo.toml:
foo = { git = 'https://github.com/ParadoxSpiral/mpv-rs.git' }
Yeah I know, that's what I'm doing right now.
But I can't publish a crate depending on mpv that way.
What's preventing me from publishing is that @Cobrand's crate already took the name.
Though thinking about it the name libmpv-rs might actually make more sense anyways.
Maybe @Cobrand is willing to hand over the crate name to you?
Failing that, libmpv sounds good to me. Duplicate crate names are inevitable at some point.
I'm not too fond of sharing the name, not because I don't trust ParadoxSpiral, but because it might cause issues for users. This repo is not an upgrade of my previous, it's a different version entirely. Currently this repo's version is 0.1.0, but my crate's version is 0.2, so you'd need to update it to at least 0.3.
On crates.io there will be this awkward scenario where 0.3 's repository will be yours, but 0.2 (and lower)'s repository will be mine.
Because of this (and I'm sure there are other reasons as well), I'd prefer if you could create another name on crates.io. I could push an update on my repo to redirect from the readme to your crate, but I'm not too fond of sharing the same name for now.
I agree, that would be awkward. A shame that crates.io does not support namespaces.
An issue would be that renaming the crate would break all crates that depend on the git, though I think that could be solved by reexporting libmpv-rs from a facade mpv-rs for the meanwhile.
Small update: I have the repo restructured locally and it works. However I've noticed weird behaviour around event handling where events seem to spuriously not fire which I want to checkout before releasing a major version bump.
So I've been thinking about this, and in hindsight the events_sync feature seems severely overengineered to the point I might just rip it out, and make mpv.wait_event safe by constraining it to one thread. Do you use the events_sync feature?
This crate has been published under the libmpv and libmpv-sys names.
Great, thanks.