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

Develop 0.4.4-beta.* #35

Closed
qryxip opened this issue May 24, 2022 · 6 comments · Fixed by #39
Closed

Develop 0.4.4-beta.* #35

qryxip opened this issue May 24, 2022 · 6 comments · Fixed by #39

Comments

@qryxip
Copy link
Collaborator

qryxip commented May 24, 2022

Maybe we should release new versions of crates as 0.4.4-beta.*.

Currently, some people do not seem to use 0.3 but 0.4 for AtCoder. Adding new features such as #26 and #27 may lead to "what the hell my program compiles with Rust 1.42 on the local machine but the submission is CE".

Making the versions beta will prevent such a situation because both the (currently unstable) built-in cargo add command and the cargo-add command from cargo-edit does not resolve -beta versions without explicit specification.

@qryxip
Copy link
Collaborator Author

qryxip commented May 24, 2022

And/Or setting lib.name to "proconio_beta" prevent such a situation, too.

[lib]
name = "proconio_beta"

This renaming is also useful for using both 0.3 and 0.4 on AtCoder with a bundling tool such as cargo-equip.

use proconio::input; // enough for this problem
//use proconio_beta::input;
//use proconio::input;
use proconio_beta::input; // I want to use a new feature for this problem

@qryxip
Copy link
Collaborator Author

qryxip commented May 24, 2022

does not resolve -beta versions without explicit specification

Example: https://docs.rs/salsa

@statiolake
Copy link
Owner

Thank you for a good opinion! First of all, I also think we should make it hard to use v0.4 to AtCoder users.

I'm concerning, however, that using prerelease versioning (including renaming to *_beta) maybe a cause of confusion.

  • To disable all v0.4.x, I need to yank v0.4.3, since it already contains features incompatible with AtCoder.
    (discraimer: I'm not familiar with cargo's behavior. Also I'm not sure how users prepare their project before contest.) I think most users are reusing their Cargo.toml among contests. If it contains previously generated proconio = "0.4.3", I think it causes an error (without previously generated Cargo.lock). This is not a big issue if using some helper tools is most popular way and the tools handle this properly.
  • (less important) Other usage not restricted by AtCoder's version (such as including this crate to another judge service, using this crate in simple standalone command line tools, using this crate with some bundle tools, and so on) should use rather v0.4.x. To tell those users to use "beta" version (semantically it is a normal v0.4.x) seems a bit unnatural for me. However, since proconio's primary target is AtCoder, it is less important thing.

This is just my thought. What do you think?

@qryxip
Copy link
Collaborator Author

qryxip commented May 29, 2022

If it contains previously generated proconio = "0.4.3", I think it causes an error (without previously generated Cargo.lock).

That's true. Yanked crates cannnot be resolved without Cargo.lock, though they are still even downloadable if Cargo.lock remains(※). Just yanking previous v0.4.* would defeat the purpose.

(※) How to confirm this
# crossbeam v0.5.2 is yankedrm ~/.cargo/registry/cache/git.luolix.top-1ecc6299db9ec823/crossbeam-channel-0.5.2.cratecargo init
     Created binary (application) packagecargo add 'crossbeam-channel@=0.5.0'
    Updating 'https://github.com/rust-lang/crates.io-index' index
      Adding crossbeam-channel =0.5.0 to dependencies.
             Features:
             + crossbeam-utils/std
             + std
             - crossbeam-utilscargo generate-lockfile
    Updating crates.io indexsed 's/"=0\.5\.0"/"0.5.2"/' -i ./Cargo.tomlsed \
>   -e '/^name = "crossbeam-channel"$/{n;s/0\.5\.0/0.5.2/}' \
>   -e 's/"dca26ee1f8d361640700bde38b2c37d8c22b3ce2d360e1fc1c74ea4b0aa7d775"/"e54ea8bc3fb1ee042f5aace6e3c6e025d3874866da222930f70ce62aceba0bfa"/' \
>   -Ei ./Cargo.lockcargo check
  Downloaded crossbeam-channel v0.5.2
  Downloaded 1 crate (87.8 KB) in 1.40s
   Compiling crossbeam-utils v0.8.8
    Checking cfg-if v1.0.0
    Checking lazy_static v1.4.0
    Checking crossbeam-channel v0.5.2
    Checking pkg v0.1.0 (/tmp/pkg)
    Finished dev [unoptimized + debuginfo] target(s) in 2.58s

How about this?:

  1. Release v0.4.4 with the following item in proconio/src/lib.rs.

    #[allow(path_statements, clippy::no_effect)]
    const _: () = {
        THIS_VERSION_OF_PROCONIO_IS_DEPRECATED;
    
        #[deprecated(note = "Using proconio v0.4.4 is deprecated. \
            This version exists only for avoiding the \
            \"failed to select a version for the requirement\" error during a contest. \
            From next time, please use v0.3 or v0.4.5-beta.* instead")]
        const THIS_VERSION_OF_PROCONIO_IS_DEPRECATED: () = ();
    };
  2. Yank 0.4.0, v0.4.1, v0.4.2, and v0.4.3.

  3. Start developing v0.4.5-beta.1.

To tell those users to use "beta" version (semantically it is a normal v0.4.x) seems a bit unnatural for me.

I've forgotten CafeCoder. This competitive programming service currently returns HTTP 500, but if I remember correctly, it is providing proconio v0.4.

@statiolake
Copy link
Owner

statiolake commented May 31, 2022

Thanks for detailed explanation. Deprecating v0.4 still doesnt seem a good way to me, considering that v0.4 is in fact better version for new users and there's actually another service (CafeCoder) using this, but adding warning is a good idea!

So how about this: adding atcoder_warning feature to this, and make it default feature. Emit a warning if the feature is enabled. ("deprecated" is a bit misleading message but there's no compile_warning! macro in std...) When users use this crate in another place, tell them to disable the feature or just ignore the warning. When AtCoder updates proconio to v0.4.x, publish new version v0.4.y removing this warning and start v0.5 (if needed) in the same way.

@qryxip
Copy link
Collaborator Author

qryxip commented Jun 5, 2022

adding atcoder_warning feature

Yes, switching the warning is the most reasonable way to me, but how about adding non-default not-for-atcoder202004 feature instead and making it default when next judge system update is completed?

proconio may be used as a dev-dependency for library crates that are bundled by cargo-equip, cargo-executable-payload, or cargo-atcoder. Suppressing the warning in such case might be difficult because features are easy to enable but hard to disable.

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

Successfully merging a pull request may close this issue.

2 participants