These are chat archives for rust-lang/rust

8th
Mar 2018
bspeice
@bspeice
Mar 08 2018 01:35
OK, so this is random: If I start a new library project, add log = "0.3.6" as the only dependency, and build, Cargo downloads and compiles in both log v0.4.1 and v0.3.9. Am I the only person who thinks that may be crazy?
This is on Rust 1.24.0, cargo 0.25.0.
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 02:00
hmmm. I'll try that as well.
yah it does that for me as well. I have no idea O.o
bspeice
@bspeice
Mar 08 2018 02:13
OK. I'll file a bug report, that seems broken.
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 02:13
I'm no expert, I'm trying to understand the logic here.
the thing I'm looking at is that it seems to expect you to only specify the major and minor version number.
I think cargo tries to take you to the latest version unless you have it in your cargo.lock file? but then it downloads 0.4? I got no idea.
OH. @bspeice I know why it's bringing in 0.4.1
[[package]]
name = "log"
version = "0.3.9"
source = "registry+https://github.com/rust-lang/crates.io-index"
dependencies = [
 "log 0.4.1 (registry+https://github.com/rust-lang/crates.io-index)",
]
still haven't figured out the 0.3.9 thing tho.
bspeice
@bspeice
Mar 08 2018 02:20
...wait, so why do previous versions of a package depend on newer ones? rust-lang-nursery/log@c946380
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 02:21
Hmm I would say to act as a wrapper to the mainline code without breaking any API's
I guess they broke the API when they switched the minor version number? seems pretty silly to me. You're not supposed to do that.
bspeice
@bspeice
Mar 08 2018 02:21
So allow people to use 0.4 code within a 0.3 package? And prior to 1.0, I think semver allows you to do whatever.
And looks like log 0.3.6 doesn't have the same trick, so still not sure why Cargo is resolving to 0.3.9 https://github.com/rust-lang-nursery/log/tree/1c79a9c8ddebce3f0037fcdc6783e682cb87bce2
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 02:23
yah I figure 0.3 is just an api wrapper to 0.4, that's my guess.
so, theory: I think cargo ignores the patch number, on the theory that patches arn't supposed to break anything and likely include security fixes, and instead depends on the cargo.lock file for stability
0.3.9 is a patch upgrade of 0.3.6 (also you were right about that 0.x.x thing in semver. )
nah the docs specify the full version number <:\
bspeice
@bspeice
Mar 08 2018 02:27
Yeah, that seems fundamentally broken if your build tool is willing to ignore explicit instructions.
Actually, maybe it is ignoring things. Just tried to use rand = "0.4.1" (where 0.4.2 is the latest) and Cargo definitely just picked up 0.4.2.
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 02:29
hey I just tried this and it worked! log = "<=0.3.8"
gave me 3.8
bspeice
@bspeice
Mar 08 2018 02:30
Yeah, "=0.4.1" works.
Great find, thanks.
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 02:30
yah "=0.3.6" works
bspeice
@bspeice
Mar 08 2018 02:37
Thanks for the help.
Noah Weninger
@nwoeanhinnogaehr
Mar 08 2018 04:58
What's going on here? Known issue?
error[E0277]: the trait bound `T: std::marker::Sized` is not satisfied
 --> src/main.rs:4:46
  |
4 | struct Opaque<T: Sized>(PhantomData<T>, [u8; mem::size_of::<T>()]);
  |                                              ^^^^^^^^^^^^^^^^^ `T` does not have a constant size known at compile-time
  |
  = help: the trait `std::marker::Sized` is not implemented for `T`
  = help: consider adding a `where T: std::marker::Sized` bound
  = note: required by `std::mem::size_of`
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 05:02
that should be fine as long as it's not dynamic dispatch right?
Oh wait, It's a marker trait you need to specify, so you'd see this even if it would work.
oh but it's specified <:| no idea.
Denis Lisov
@tanriol
Mar 08 2018 09:42
@nwoeanhinnogaehr #43408
Noah Weninger
@nwoeanhinnogaehr
Mar 08 2018 14:18
Thanks!
Yuji Kanagawa
@kngwyu
Mar 08 2018 15:49
Is there any good example of proc_macro_derive implementation?
Now I referece stdweb-derive and it's well written, but I want to read more.
Restioson
@Restioson
Mar 08 2018 18:14
@Ghoughpteighbteau giving cargo log = "0.3.8" will just make it use the most recent compatible release
shouldnt be a need for stuff like < imo
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:24
yah, that discussion was about our surprise that 0.3.6 meant ^0.3.6 and not =0.3.6. I think bspeice wanted 0.3.6 specifically.
Thinking about it, I can see why cargo made that decision, just saying 0.3.6 could be considered the default specifier, and default should allow important patches to propagate.
Restioson
@Restioson
Mar 08 2018 18:25
yeah but tbh unless the crate authors hasnt followed semver its the same
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:26
bspeice pointed out that in semver, you can do whatever you want to the API so long as you're in the 0.x.x's which means in this case it might not be the same.
(but I think it was anyway :P )
Restioson
@Restioson
Mar 08 2018 18:26
no
0.x can be breaking
0.*.x can never
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:27
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
I was surprised as well.
Restioson
@Restioson
Mar 08 2018 18:28
Im pretty sure patch is still only for patches
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:28
personally, so would I.
only use patches for patches.
Denis Lisov
@tanriol
Mar 08 2018 18:28
Well, this is the variation of semver used around Rust :-)
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:28
lol
semver.rs
Restioson
@Restioson
Mar 08 2018 18:29
im not sure any time is correct?
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:29
Look restioson I agree with you, but look at the spec of semver, they make pains to say that all the rules for major and minor don't apply to 0.x.y :\
James McCoy
@jamessan
Mar 08 2018 18:30
That doesn't mean you can't hold yourself to a higher standard, but that's what 0.x.y communicates
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:31
yah I don't get why they make this exception... Maybe there's a reason?
James McCoy
@jamessan
Mar 08 2018 18:32
So that there's room to figure out what your API is going to be during initial development
The options are either do everything behind closed doors, don't make releases, or make releases and communicate that the API isn't guaranteed
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:37
you are inferring it wrongly
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:43
0.whatever will be breaking doesn't mean that 0.1.2 shouldn't be compatible with 0.1.1
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:44
do you mean that in the ethical sense, the semver.rs sense, or the semver.org sense? :P
James McCoy
@jamessan
Mar 08 2018 18:44
I never said it couldn't or shouldn't be, but it can be because no API guarantees are made during 0.x.y releases
That's the definition of semver
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:46
i have rarely seen any crates break "intentionally" in a minor pre-1 release
also this has nothing to do with rust, but other languages also follow the same pattern
James McCoy
@jamessan
Mar 08 2018 18:46
Again, projects can certainly hold themselves to stricter standards than semver communicates. There's nothing wrong with that. All that's being discussed is whether compatibility can be broken for 0.x.y releases
After all, breaking changes would necessitate going from 0.x.y to 1.a.b for a compatibility break if you were following the normal semver semantics
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:48
Yah, I agree with James, also because compatibility can be broken, is it OK for cargo to assume it wont? Even though we can agree that it would be somewhat sensible not to break. Should it follow the standard or what most people would think is good practice?
James McCoy
@jamessan
Mar 08 2018 18:48
But those are explicitly discarded for 0.x.y
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:48
not necessrily
i mean you can go from 0.1 to 0.2 right?
those are assumed to be "breaking" anyway
James McCoy
@jamessan
Mar 08 2018 18:48
Yes, necessarily. Only backwards compatible changes can be made for a change to a patch or minor version
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:48
I think semver is saying that 0.1.1->0.1.2 could be breaking as well.
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:48
nope
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:49
yup :(
lol
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:49
semver says that 0.1.0 to 0.2.0 can be breaking
James McCoy
@jamessan
Mar 08 2018 18:49
Nope
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:49
not 0.1.0 to 0.1.1
so for pre-1 releases, the bits shift once to the right
James McCoy
@jamessan
Mar 08 2018 18:49
There are no semantics for patch or minor versions for 0.x.y, other than what the project imposes
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:50
meaning?
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:50
lol james I was trying to figure out if your "nope" was disagreeing with me or being a double negative.
James McCoy
@jamessan
Mar 08 2018 18:50
Meaning you can do anything for 0.x.y releases.
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:50
:joy:
semver spec says that 0.1.1 -> 0.1.2 is a minor release and should be backwards compatible
James McCoy
@jamessan
Mar 08 2018 18:50
No
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:50
:shrug:
damn :P
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:50
dylan you should check out the spec man
James McCoy
@jamessan
Mar 08 2018 18:50
Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:51
sec
both of us are quoting 2 different parts of the spec :joy:
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:51
it's not just that rule, but all the rules are accounting for the 0 release
Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:52
that's for x > 0
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:52
which is not true if x = 0 :P
James McCoy
@jamessan
Mar 08 2018 18:52
Right, because nothing matters for 0.x.y
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:52
iknow
but uhmm
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:53
I was surprised as well <.<
James McCoy
@jamessan
Mar 08 2018 18:53
Again, this is purely according to spec. The spec doesn't prevent you from being stricter about the versioning as long as the overall semantics still apply
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:54
it also says this though: my bad..
turns out what i was quoting wasn't in the spec
but in docs of a package manager
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:55
which package manager out of curiosity?
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:55

However it does say this:

The simplest thing to do is start your initial development release at 0.1.0 and then increment the minor version for each subsequent release.

by minor do they mean the 'y' or the 'z'
@Ghoughpteighbteau composer (PHP)
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:56
major.minor.patch, so y
James McCoy
@jamessan
Mar 08 2018 18:56
Minor version Y (x.Y.z
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:56
ah.
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:56
no because normally for pre-1 releases people consider 0.x.y that's why i asked :D
Ghoughpteighbteau
@Ghoughpteighbteau
Mar 08 2018 18:57
lol yah I mentally would shift them down as well. 0.x.y.z I guess. Why not 0.0.x.y.z ooo. I feel like I should make an RFC
Dylan DPC
@Dylan-DPC
Mar 08 2018 18:57
:D
Fredrik Portström
@portstrom
Mar 08 2018 23:01
Hello! I'm planning to host a Rust workshop and Rust meetups in Prague, Czechia. Is there anything special I should know or anyone I should contact before I do it? I'd like to gather as many people as I can and grow the Rust community in Prague. Prague has plenty of software development events hosted by various companies, at which Rust currently gets zero attention. There's just one meetup group that was last active in July.