Remove `project` from dependencies

[kamoii]

Since emacs 25 project has been bundled in emacs. Listing project as dependency makes package managers install project package and use it over the bundled version. I suggest removing project from the dependencies list.

[progfolio]

For context: https://github.com/progfolio/elpaca/issues/47#issuecomment-1367450657

[karthink]

@kamoii project.el underwent significant design changes between its version in 25.1 and 28.2. consult-dir requires at least project v0.6.0, which is above the bundled version in Emacs 26.1 (which consult-dir supports). So I'm not sure how to handle this situation.

if the built-in version of project is > 0.6.0, as is the case in Emacs 28, for instance, then ideally package managers should consider the dependency fulfilled.

[whxvd]

if the built-in version of project is > 0.6.0, as is the case in Emacs 28, for instance, then ideally package managers should consider the dependency fulfilled.

FWIW, I just installed consult-dir in a recent Emacs 29 via the built-in package.el, and the non-built-in project was not installed. Didn't try with Emacs 28, though.

As far as I see it, it clearly is bug of the package manager when it installs an external package even though the built-in version already fulfills the dependency. And the "fix" for elpaca in https://github.com/progfolio/elpaca/issues/47 clearly is wrong.

[progfolio]

if the built-in version of project is > 0.6.0, as is the case in Emacs 28, for instance, then ideally package managers should consider the dependency fulfilled.

FWIW, I just installed consult-dir in a recent Emacs 29 via the built-in package.el, and the non-built-in project was not installed. Didn't try with Emacs 28, though.

As far as I see it, it clearly is bug of the package manager when it installs an external package even though the built-in version already fulfills the dependency. And the "fix" for elpaca in progfolio/elpaca#47 clearly is wrong.

Package.el takes a different approach than straight.el and Elpaca. It considers any package greater than or equal a declared dependency version "better". Unfortunately, there are several version schemas in the wild for elisp. Some people use semver, some don't use a meaningful version number at all, MELPA has a timestamp based versioning schema, etc.

So, we could special case built-in packages and make the same assumption package.el does, but that doesn't solve the general case of elisp from any other source. It's also not a great assumption because "newer" doesn't always mean compatible (though, core Emacs packages tend to be more conservative/careful in their consideration of backward compatibility).

The way Elpaca handles it is no more "wrong" than the way package.el decided to do it. Just different strategies. Elpaca gives the user the final say. One improvement that is in the works is to warn the user when a version dependency is not satisfied and let them decide how they would like to handle it.

If you have any ideas on how the situation could be improved for either package manager, please let me know.

[whxvd]

Package.el takes a different approach than straight.el and Elpaca. It considers any package greater than or equal a declared dependency version "better". Unfortunately, there are several version schemas in the wild for elisp. Some people use semver, some don't use a meaningful version number at all, MELPA has a timestamp based versioning schema, etc.

Didn't know that, and silently assumed that there was a universal well-defined and totally ordered version scheme in use everywhere.

So, we could special case built-in packages and make the same assumption package.el does, but that doesn't solve the general case of elisp from any other source. It's also not a great assumption because "newer" doesn't always mean compatible (though, core Emacs packages tend to be more conservative/careful in their consideration of backward compatibility).

Didn't consider that, either.

The way Elpaca handles it is no more "wrong" than the way package.el decided to do it. Just different strategies. Elpaca gives the user the final say. One improvement that is in the works is to warn the user when a version dependency is not satisfied and let them decide how they would like to handle it.

Then no version dependency will be broken silently. From my limited understanding, that seems essentially safe enough.

If you have any ideas on how the situation could be improved for either package manager, please let me know.

No, at least nothing that almost certainly already has been considered, already is possible, or lacks other considerations. (Making it possible to pin a package to the built-in version, to ignore specific dependencies of specific packages (in specific ways), and to break in every suspicious and not correctly ignored case.)

I also do not consider it unreasonable anymore to drop the dependency on project from this package, as long as the Emacs depended upon continues to already fulfill the version dependency for project. But I don't know. Sorry for the noise.

[karthink]

I also do not consider it unreasonable anymore to drop the dependency on project from this package, as long as the Emacs depended upon continues to already fulfill the version dependency for project. But I don't know. Sorry for the noise.

Actually consult requires Emacs 27.1 or higher now, so it doesn't make sense for consult-dir to support Emacs 26 anymore. Can someone using Emacs 27.1 verify that the bundled version of project is > 0.6? If this is the case, I can drop the project requirement and this problem goes away completely.

[progfolio]

https://github.com/emacs-mirror/emacs/commit/3b32d057ff2258177fdcd90cd70836ec2ad45f86

$ git tag --contains 3b32d057ff2258177fdcd90cd70836ec2ad45f86 | head -n1

emacs-28.0.90

That's for the change from 0.6 to 0.6.1. The version I see in a dockerized Emacs 27.1 doesn't have the Version header metadata at all, so It's probably older than what you're targeting.

[karthink]

Very well then, I've removed project from the list of dependencies for Consult dir. Emacs 26 is no longer supported. I think that resolves the issue.

[whxvd]

I also do not consider it unreasonable anymore to drop the dependency on project from this package, as long as the Emacs depended upon continues to already fulfill the version dependency for project. But I don't know. Sorry for the noise.

Actually consult requires Emacs 27.1 or higher now, so it doesn't make sense for consult-dir to support Emacs 26 anymore. Can someone using Emacs 27.1 verify that the bundled version of project is > 0.6? If this is the case, I can drop the project requirement and this problem goes away completely.

Recursive blaming yields the following:

Version bump	Commit
0.6.0 → 0.6.1	3b32d057ff2258177fdcd90cd70836ec2ad45f86
0.5.4 → 0.6.0	1054525ae3795b71fe09dafcbb86d3cdb1d7f875
0.5.3 → 0.5.4	2a71831eb3dcd122ee4f91254b31a801922c7917
0.5.2 → 0.5.3	2d790c6c57b244447390c023679752243e0049c9
0.5.1 → 0.5.2	5142149758333cfddc25c8c696e0e6f322e37d62
0.5.0 → 0.5.1	319463920ca8829dcdfa6c0c8c1c8ff15091f6f0
0.4.0 → 0.5.0	3c7bae233770373c5183073a3ddcb466b328cfc9
0.3.0 → 0.4.0	3b32d057ff2258177fdcd90cd70836ec2ad45f86
0.2.0 → 0.3.0	3f66908ee0821d638ec9bf4360400cbd2e58f70a
0.1.3 → 0.2.0	2216468786f64cfa403dface1dab1cd20b84d5aa
0.1.2 → 0.1.3	1fc4e3fb3f6caba6a4ca69060c7992ea5d24ff36
0.1.1 → 0.1.2	afca37343d0637386e4dfc4fb04d8700f3c6bf0d
0.1 → 0.1.1	779bc886f9bc2e3188bf2577c3df2ae662ca1b98
0.1	9ebf51999ce58cccc2a228fd07a18c7b472dd3fd

The last commit is from 2020-05-13 and contains "lisp/progmodes/project.el: Add Version and Package-Requires" in the commit message.

All commits come after the first Emacs 27 pretest, but are included neither in Emacs 27.1 nor in Emacs 27.2.

So almost certainly the whole Emacs 27 series contains a project that had been frozen to a pre-0.1 state.

Very well then, I've removed project from the list of dependencies for Consult dir. Emacs 26 is no longer supported. I think that resolves the issue.

If consult-dir depends on version 0.6 (or any version at all) of project, then depending on Emacs 27.1 and dropping the dependency for project almost certainly is not sufficient. (Sorry again for starting all this hassle.)

(FWIW, Emacs 28.1 contains version 0.8.1 of project.)