diesel migration generate create_users does not work anymore

[ivanceras]

This used to work on early versions of disel_cli, but now I re-installed diesel_cli 0.9.0 it will keep displaying the help message.

$diesel migration generate create_users
diesel-migration-generate 
Generate a new migration with the given name, and the current timestamp as the version

USAGE:
    diesel migration generate [OPTIONS] <MIGRATION_NAME>

FLAGS:
    -h, --help    Prints help information

OPTIONS:
        --database-url <DATABASE_URL>            Specifies the database URL to connect to. Falls back to the DATABASE_URL environment variable if unspecified.
        --migration-dir <MIGRATION_DIRECTORY>    The location of your migration directory. By default this will look for a directory called `migrations` in the
                                                 current directory and its parents.
        --version <MIGRATION_VERSION>            The version number to use when generating the migration. Defaults to the current timestamp, which should
                                                 suffice for most use cases.

ARGS:
    <MIGRATION_NAME>    The name of the migration to create

However with a correct .env with the DATABASE_URL set correcly, diesel setup works and creates the needed database and tables.

Tested both on MacOS and ubuntu 16.04, with the same behavior.

[killercup]

I saw this failure as well but couldn't reproduce it locally. Are you using the 0.9 from crates.io or from git master? Did maybe one of our dependencies change? (We use clap for the CLI.) ivanceras <notifications@github.com> schrieb am Mi. 1. Feb. 2017 um 07:40:

…

This used to work on early versions of disel_cli, but now I re-installed diesel_cli 0.9.0 it will keep displaying the help message. $diesel migration generate create_users diesel-migration-generate Generate a new migration with the given name, and the current timestamp as the version USAGE: diesel migration generate [OPTIONS] <MIGRATION_NAME> FLAGS: -h, --help Prints help information OPTIONS: --database-url <DATABASE_URL> Specifies the database URL to connect to. Falls back to the DATABASE_URL environment variable if unspecified. --migration-dir <MIGRATION_DIRECTORY> The location of your migration directory. By default this will look for a directory called `migrations` in the current directory and its parents. --version <MIGRATION_VERSION> The version number to use when generating the migration. Defaults to the current timestamp, which should suffice for most use cases. ARGS: <MIGRATION_NAME> The name of the migration to create However with a correct .env with the DATABASE_URL set correcly, diesel setup works and creates the needed database and tables. Tested both on MacOS and ubuntu 16.04, with the same behavior. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#602>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABOX62gtYB2buaW3vmn1F8rh0YKuSW8ks5rYCjLgaJpZM4Lzic8> .

[ivanceras]

Yes, by installing it via cargo install diesel_cli

I'm using rust nightlies

$cargo -V
cargo 0.17.0-nightly (40a4ce6 2017-01-06)
$rustc -V
rustc 1.16.0-nightly (47c8d9fdc 2017-01-08)

[ggrochow]

I'm also having this error, Debian 8.7
Just following along with the getting started, diesel setup worked fine.

diesel 0.9.0
rustc 1.16.0-nightly (df8debf6d 2017-01-25)
cargo 0.17.0-nightly (67e4ef1 2017-01-25)

I also did a cargo install diesel_cli --vers 0.8 and it still gave me same migration error.

[drbawb]

I'm also running into this problem:

Mac OS 10.11.16
rustc 1.16.0-nightly (df8debf6d 2017-01-25)
cargo 0.17.0-nightly (67e4ef1 2017-01-25)
diesel 0.9.0

The command was installed w/ cargo install diesel_cli

diesel setup worked fine, diesel migration generate create_entries did create the migrations/ folder, but it did not create the migration files. The CLI usage text is outputted to the console instead.

[weiznich]

@killercup I'm able to reproduce this, as you assumed this related to dependency change. Building diesel with clap 2.19 will produce a fully working build, but building with 2.20 (the most current version) will produce a build that showed the described issue.

[killercup]

So it's a breaking change in clap? cc @kbknapp

@weiznich, why would it ever load a clap ≥ 2.11, though? diesel_cli contains a Cargo.lock :O

I really hope this has nothing to do with workspaces :/ (or I'll need to cc some more people)

[weiznich]

It seems like that this lock is ignored because diesel uses a cargo workspace and therefore a common lock file for all workspace members. The common lock file should be located in the workspace root.

[kbknapp]

Interesting. I'm not aware of any breaking changes in from clap 2.19 to 2.20. I'll look into this more and see if I can find anything.

[kbknapp]

It's possible it could be a regression bug, would someone mind filing an issue on the clap repo? I'm on mobile right now. Also compiling clap with the features = ["debug"] will help as well.

[killercup]

Quick workaround: clap = "=2.19.3". We should probably remove diesel_cli from the workspace for now.

[sgrif]

/cc @alexcrichton it looks like there's also no way for us to opt just the one crate out of being in the workspace? What's the best option here since binaries are supposed to check in their Cargo.lock?

[sgrif]

I'm going to remove the Cargo.lock from the tree as well, since crates.io will never use it by the look of things.

[kbknapp]

I'm looking into this bug as we speak, if it's what I think is happening I should have a fix out momentarily.

…

On Feb 2, 2017 3:09 PM, "Sean Griffin" ***@***.***> wrote: I'm going to remove the Cargo.lock from the tree as well, since crates.io will never use it by the look of things. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#602 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGnttvgR8PW-jXZvGzyYzc9vInBU9LWSks5rYeOUgaJpZM4Lzic8> .

[alexcrichton]

@sgrif thanks for the cc! Yeah currently there's no opt-out, but that's tracked at rust-lang/cargo#3192