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.

Sign up for GitHub

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

Jump to bottom

UI Differentiating between Initializing vs Updating #61

Open
epage opened this issue Aug 26, 2021 · 1 comment
Open

UI Differentiating between Initializing vs Updating #61

epage opened this issue Aug 26, 2021 · 1 comment
Labels
enhancement help wanted

Comments

@epage
Copy link
Contributor

epage commented Aug 26, 2021

I was looking at using crates-index in cargo-edit and noticed in master that instantiating an Index will retrieve if needed, compared to before where the two actions were distinct.

No idea if cargo-edit considers this important but provides a different user message for retrieve vs update (Initializing vs Updating).
epage added a commit to epage/cargo-edit that referenced this issue Aug 27, 2021
@epage
refactor: Pun index logic to crates-index
202d714 
This was inspired by running into errors where `cargo add inquire` was
not adding the latest version.  We've seen similar problems during the
development of `crates-index`, so hoping what they've done fixes this.

Even if it doesn't solve this problem, hopefully by nature of using a
shared crate means it will get more use and more eyes to make it more
reliable in the long term.

Handling retrying the index is annoying.  I opened
frewsxcv/rust-crates-index#62

Note: in the next version of crates-index
- Opening an index will implicitly create it, so we won't be able to
  differentiate in our message whether we are initializing or updating.
  See frewsxcv/rust-crates-index#61
- We will be able to open an Index by URL, which will allow us to remove
  more logic
@epage epage mentioned this issue Aug 27, 2021
Merged
epage added a commit to epage/cargo-edit that referenced this issue Aug 30, 2021
@epage
refactor: Pun index logic to crates-index
55d7de2 
This was inspired by running into errors where `cargo add inquire` was
not adding the latest version.  We've seen similar problems during the
development of `crates-index`, so hoping what they've done fixes this.

Even if it doesn't solve this problem, hopefully by nature of using a
shared crate means it will get more use and more eyes to make it more
reliable in the long term.

Handling retrying the index is annoying.  I opened
frewsxcv/rust-crates-index#62

Note: in the next version of crates-index
- Opening an index will implicitly create it, so we won't be able to
  differentiate in our message whether we are initializing or updating.
  See frewsxcv/rust-crates-index#61
- We will be able to open an Index by URL, which will allow us to remove
  more logic
epage added a commit to epage/cargo-edit that referenced this issue Aug 31, 2021
@epage
refactor: Pun index logic to crates-index
cbc8ad9 
This was inspired by running into errors where `cargo add inquire` was
not adding the latest version.  We've seen similar problems during the
development of `crates-index`, so hoping what they've done fixes this.

Even if it doesn't solve this problem, hopefully by nature of using a
shared crate means it will get more use and more eyes to make it more
reliable in the long term.

Handling retrying the index is annoying.  I opened
frewsxcv/rust-crates-index#62

Note: in the next version of crates-index
- Opening an index will implicitly create it, so we won't be able to
  differentiate in our message whether we are initializing or updating.
  See frewsxcv/rust-crates-index#61
- We will be able to open an Index by URL, which will allow us to remove
  more logic
ordian pushed a commit to killercup/cargo-edit that referenced this issue Aug 31, 2021
@epage
refactor: Pun index logic to crates-index (#484)
a2d99c1 
This was inspired by running into errors where `cargo add inquire` was
not adding the latest version.  We've seen similar problems during the
development of `crates-index`, so hoping what they've done fixes this.

Even if it doesn't solve this problem, hopefully by nature of using a
shared crate means it will get more use and more eyes to make it more
reliable in the long term.

Handling retrying the index is annoying.  I opened
frewsxcv/rust-crates-index#62

Note: in the next version of crates-index
- Opening an index will implicitly create it, so we won't be able to
  differentiate in our message whether we are initializing or updating.
  See frewsxcv/rust-crates-index#61
- We will be able to open an Index by URL, which will allow us to remove
  more logic
@Byron
Copy link
Collaborator

Byron commented Jul 29, 2023

I think that if there was a way to instantiate a GitIndex without auto-initialization, maybe by returning None if the index doesn't exist, that would allow the caller to know if GitIndex::new_cargo_default() would initialize the index.

As far as I know, GitIndex::update() always has to be called explicitly, so there should be no issue in making that clear UI wise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@epage @Byron