lucky_cli
lucky_cli copied to clipboard
lucky --version should also print the included framework versions
Instead of just printing 0.7.1 (or whatever the current version is), lucky --version
should print out the versions each included framework it's going to create with lucky init
$ lucky --version
lucky_cli: 0.7.1
lucky: 0.6.2
lucky_migrator: 0.3.0
I wonder what people expect this to print out. It seems obvious when not inside of a project, but would people expect it to show the versions currently installed in the shard.yml file, or the versions the executable will create?
RSpec does this well:
$ rspec -v
RSpec 3.7
- rspec-core 3.7.0
- rspec-expectations 3.7.0
- rspec-mocks 3.7.0
- rspec-rails 3.7.2
- rspec-support 3.7.0
@edwardloveall Do you still see this as relevant? I was thinking about this, and feel like this could be confusing. For me, I just need to know the Lucky version I'm on, and then assume that all other versions (Dexter, Carbon, Avram, Wordsmith, Flow, Authentic, Habitat, Router) would just be the latest that is supported with that version of Lucky. Plus, that's a lot of shards we'd show 😅
Hmmm... maybe. I could see it being useful but I don't think it needs to be -v
. I could easily see it coming from a separate option like --framework-versions
. The reason I like having something like this is it helps with support.
User: I'm having an issue with X. Me: Can you run
lucky --framework-versions
and paste the result here?
I don't feel like it's critical though. We have the shards.yml file.
Cool. I like that.
Could we get the same (or similar) info by asking for the shard.lock
? I imagine that's what --framework-versions
would use under the hood.
I don't think so because in some cases it would show up with a commit hash instead of version number.
That seems like it'd be really good to know. Since if they're using a specific commit it may not be the officially released version. But I may be thinking about this wrong
Ah, I see what you're saying. I would be good with either way.