This avoids recollecting the cache files over and over again.
For example, `dvc fetch` noop in `dvc-bench` went from ~30sec down to ~10sec
for me.
Next step is to also cache remote index, so we don't have to waste those
~10sec checking files in the remote.
Related https://github.com/iterative/dvc-data/pull/376
Makes dvc get/import/etc use dvcfs, which already supports cloud versioning,
circular imports and other stuff.
Also makes dvc import behave more like dvc import-url, so that we can use
the same existing logic for fetching those using index instead of objects.
Fixes#8789
Related iterative/studio#4782
* bump ruff to v0.0.247
* ruff: enable pep8-naming check
rename some camelCased APIs, especially in logger
rename G variables to graph
ignore some variable namings and help messages in dvc.commands
Extracting from `index.data` as a "root" data index that contains indexes
for different revisions/workspaces.
This is a setup for putting cloud versioning remote indexes and also replacing
old state.
We used to have it named `cache` before, but these days it is clear that
you can have three odbs: just odb (e.g. in-memory), cache (typically local)
or remote (typically cloud). Fixing naming here before proceeding with
introducing `out.odb` and `out.cache`.
In preparation for migration to https://github.com/iterative/dvc-data/pull/304
add --no-download flag to dvc import-url/dvc update to only create/update .dvc
files without downloading the associated data.
Created .dvc files can be fetched using `dvc pull` or can be
updated using `dvc update --no-download`.
This commit moves `HashedStreamReader`/`get_hash_file`/`file_md5`
into `dvc.objects.hash`.
The `get_hash_file` has been renamed to `hash_file`.
This also copies `relpath` and `is_exec` to the `dvc.fs.utils`.
By splitting dvc.cli into a module, we'll be able to share cli-related
utilities, split parser-related stuffs into smaller parts, improve
reusability and improve API for command extensions in the future.
Initial simple separation to get the process of extracting dvc-objects
and dvc-data packages out of dvc.
dvc-objects is for:
* defining base Object (aka HashFile) and ObjectDB
* providing tools to work with those objects (check/transfer/etc)
* etc
dvc-data is for:
* defining higher level objects (e.g. Tree)
* bulding objects from the workspace (aka staging)
* projecting objects back into the workspace (aka checkout)
* comparing Tree objects (aka diff)
* defining misc object databases (e.g LocalObjectDB)
* higher-level transfer (e.g. with Tree indexes)
* etc
For example, the objects we use in run-cache are based on dvc-objects
and not on dvc-data, as they have absolutely nothing to do with data
management.
There are still some mixups in the code that will be addressed in the
followups.
With introduction of https://github.com/iterative/dvc-plugins,
all important tests are being ran there, so there is no need
for dvc repo to run them again.
This PR also removes some redundant/broken remote tests.
This is a very early version of test utils for dvc plugins. This module
consists of existing tests with minimal changes and is going to evolve
a lot as our plugins are getting filled in and pytest-test-utils matures.
Ruslan Kuprieiev
skshetry
pre-commit-ci[bot]andSaugat Pachhai
Peter Rowlands
David de la Iglesia Castro
Ronan Lamy
Daniele Trifirò
Karthikeyan Singaravelan
Nick Sorros
