Only import from conda if current_repodata is generated

[dholth]

Description

Reduce or remove conda dependencies.

Fix #244

Checklist - did you ...

• Add a file to the news directory (using the template) for the next release's release notes?
• Add / update necessary tests?
• Add / update outdated documentation?

[dholth]

If --current-repodata is passed then check for "import conda"; ask user to install conda or pass --no-current-repodata. Should happen in the CLI entry point before this is called.

[jezdez]

I don't agree with this approach or the core of the ticket it tries to close; it puts a maintenance burden on conda-index for almost no gain, which we already struggle with.

The better strategy is the one we've been following but not sufficiently executed on since conda-index was maintained underresourced and independent from the conda release cycle: conda is the bottom of the well, implementing core primitives, which conda-index should be importing using the Python import system.

If new features of conda-index require new versions of conda, it should bump up the lower versions of conda to the version of the required feature.

[jezdez]

I'm not in favor of this since versions are quite possibly the most important part to reuse from conda and it puts maintenance burden to keep this in sync, for which I have little confidence we'll be able to afford

[dholth]

This is used to generate another optional file channeldata. The indexer uses version comparison to choose the newest version of a package from a random subdir, as a representative for that package in channeldata.json.

[dholth]

@jezdez #257 separates the locking concern from the vendoring concern.

[dholth]

I don't agree with this approach or the core of the ticket it tries to close; it puts a maintenance burden on conda-index for almost no gain, which we already struggle with.

The better strategy is the one we've been following but not sufficiently executed on since conda-index was maintained underresourced and independent from the conda release cycle: conda is the bottom of the well, implementing core primitives, which conda-index should be importing using the Python import system.

This premise is not correct. The conda dependency creates the maintenance burden, otherwise it's easy enough to add needed features to conda-index. By removing its conda dependency, conda-index can be a non-circular dependency of other projects; when a new conda-index feature is needed then conda can request it from conda-index.

We have also made progress updating conda's CI to require that the conda developer updates a set of dependent projects before a breaking change can be merged into conda; conda's CI started doing this for conda-build to deal with this exact issue. This moves the work to the right place, to the person who's enacting a deprecation in conda, instead of to the dependent projects that are working on something unrelated and are not familiar with that deprecation.

If new features of conda-index require new versions of conda, it should bump up the lower versions of conda to the version of the required feature.

When this is completed conda-index does not require any version of conda; it would continue to work in perpetuity until a real additional feature and not a deprecation workaround was required. This reduces the total amount of work required to maintain the conda ecosystem. To deal with today's churn, conda-index would set a maximum version of conda, not a minimum.

To me the most questionable part of this PR is the list of subdirs. The version comparison algorithm and the strings ".conda" and ".tar.bz2" are very unlikely to change in a way that is relevant to conda-index. It might be a good idea to discover the subdirs in a different way; this would also help users who wanted to bring up new platforms.