-
Notifications
You must be signed in to change notification settings - Fork 456
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.
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
dependencies within main .el file not respected #1471
Comments
Just updating the recipes' dependencies to reflect what's in the projectile.el and pkg-info.el package headers. I assume this is correct, but it somewhat mystifies me why this is necessary, as described here: dimitri#1471
Just updating the recipe's dependencies to reflect what's in the pkg-info.el package header. I assume this is correct, but it somewhat mystifies me why this is necessary, as described here: dimitri#1471
Well, the way el-get is designed, dependencies have to be installed first, so when el-get is deciding what the dependencies of a package are, it doesn't yet have access to the package's source. I don't think this issue is fixable without a rewrite. On a related note, I will try to address this issue in my rewrite. |
Ah of course, it's chicken and egg :) I thought there was probably something I was missing. However, this is identical to the problem that any other package manager ( So why do you say a rewrite would be required? I would have thought it should be reasonably easy to extend the existing code to provide a new Of course this would take a lot of time and bandwidth when run on all packages, but even doing it once a week should vastly improve the reliability of the recipes' dependency metadata. And by allowing it to run on a subset of packages enables a divide and conquer approach - it would be very easy for people to co-maintain the dependencies for their favourite list of packages in the peer-to-peer fashion which el-get so nicely implements already. We could even have client-side hooks which spot when the dependency headers are changed, and automatically update the developer's local copy of the corresponding |
I've been looking at this. When installing a package we do So the basic problem is that
So there isn't a way to just "download ... a specified package" without installing, and we can't install without knowing the correct dependencies. I have just created #2212 which adds |
@npostavs Thanks a lot for looking into this and reporting back! What you wrote makes perfect sense. Hopefully we can break it into smaller steps in the not too distant future. |
There's an additional problem that |
Maybe I'm missing something, but it looks to me like
el-get
does not respect the contents of thePackage-Requires
header within the package's main.el
file. For example, I just didM-x el-get-install pkg-info
and it failed to loadepl
despitepkg-info.el
containing the following:If I do
M-x el-get-find-recipe-file pkg-info
then I getand
M-x el-get-describe pkg-info
gives:so clearly
el-get
thinks it depends ons
when in actual fact it depends ondash
andepl
.Again, I may be misunderstanding something here, but if I'm right, this is a fundamentally broken approach, because upstream package dependencies will naturally change on a regular basis, so any model which violates DRY and expects the dependencies to be updated in more than one place will inevitably lead to frequent breakage. Sure, there may be occasions where it is necessary to model dependencies in the recipe in addition to those in the package header (e.g. if upstream fails to correctly model the dependencies), but this is not a good reason to fail to honour the package header.
The text was updated successfully, but these errors were encountered: