[Feature] An explicitly specified prerelease package should install without requiring install-prerelease

[joellabes]

Is there an existing feature request for this?

• I have searched the existing issues

Describe the Feature

I opened #4224 because I tried to install a prerelease version of dbt utils without the install-prerelease: True setting:

packages:
  - package: dbt-labs/dbt_utils
    version: 0.7.4-b1 

Requesting a prerelease package by name should be enough to trigger its installation.

Describe alternatives you've considered

No response

Who will this benefit?

Test drivers of beta packages

Are you interested in contributing this feature?

Only if no one else beats me to it

Anything else?

A potential extra for experts detailed here is to also add a --pre subcommand to dbt deps which behaves like pip install x --pre and installs prerelease versions of all first-order packages (i.e. not if you're getting dbt-utils by dependency instead of a direct reference).

[jtcohen6]

Yes, we should absolutely do this!

I was afraid the logic here would be pretty gnarly, but after a quick dive in, it's much simpler than I thought:

dbt-core/core/dbt/deps/registry.py

Lines 130 to 133 in 2241698

	installable = semver.filter_installable(
	available,
	self.install_prerelease
	)

Becomes:

        # if any prelease version is explicitly specified in any way,
        # assume we're good to use prereleases for this package
        prerelease_version_specified = any(
            bool(version.prerelease) for version in self.versions
        )
        installable = semver.filter_installable(
            available,
            self.install_prerelease or prerelease_version_specified
        )

This would have the effect of supporting both of the following:

packages:
  - package: dbt-labs/dbt_utils
    version: 0.7.4-b1 

packages:
  - package: dbt-labs/dbt_utils
    version: [">=0.7.4-b1", "<0.7.5"]

$ dbt deps
20:07:06 | [ info  ] | Running with dbt=1.0.0-rc1
20:07:06 | [ info  ] | Installing dbt-labs/[email protected]
20:07:06 | [ info  ] |   Installed from version 0.7.4
20:07:06 | [ info  ] |   Up to date!

I'd welcome a PR for this!

---

A larger question: to what extent should we try to follow PEP 404 to the letter? (I stumbled across some interesting related conversation here: pypa/pip#5503).

Namely:

• If a user explicitly specifies a prerelease version for a package, are they opting into that prerelease version? YES
• If a user includes any prerelease marker in their version specification for a package, are they opting into prereleases for that package? I say YES
• If a prerelease version is the only valid and available version, should dbt install it? This feels a bit more controversial; I think yes, but it's worth discussing more. It would require a modification to the logic in filter_installable, to prepare both installable and installable_with_prereleases, and hand back the latter if the former is unavailable.

[joellabes]

If a prerelease version is the only valid and available version, should dbt install it? This feels a bit more controversial; I think yes, but it's worth discussing more. It would require a modification to the logic in filter_installable, to prepare both installable and installable_with_prereleases, and hand back the latter if the former is unavailable.

I don't have strong feelings on this. Two options:

• silently succeed - install it because they asked for joels-cool-package and the prerelease version is the only option
• audibly fail - "joels-cool-package only has prerelease versions available. To install, set install_prerelease to true"