Dependencies missing from package #3
Comments
|
Hi, Well, some of those Specifically, the only package not included with Emacs that is loaded is Admittedly, it is a bit messy, and probably the best thing to do is a general refactoring of all 3 packages. I might do that someday, but no promises, as these are large packages that I didn't write myself. However, the packages do install and load correctly when installed from MELPA with package.el. I think the problem you're having may be caused by straight.el being more strict than package.el. The problem of using an outdated, built-in Org instead of a later version is a more general problem with Emacs package systems, AFAIK. But it shouldn't affect Outorg or Outshine, as they don't require recent Org versions. Since I'm pretty sure this is not a bug on this end, I'm going to close this issue, but feel free to continue the discussion or reopen if necessary. |
|
I strongly believe this a bug in So to summarize, yes it looks like it works with It shouldn't be necessary to do any refactoring to fix this problem. Just add |
|
@raxod502 Thanks for your insights. I'm certainly willing to add a dependency to the headers if that will fix something, but I'm not entirely clear on what the problematic behavior is that needs to be fixed here. I'm also not sure that declaring dependencies on built-in versions will make any difference, because as far as I know, these packages work fine on older Emacs versions, so I don't think there's any need to force certain versions of built-in packages. @Northcode Can you give me some specific examples of errors you've encountered? If there are some specific errors or bugs that I'm not aware of, I'll be happy to fix them, but at the moment I don't see what specifically needs to be fixed. Thanks. |
|
Sure: here, steps I used to reproduce this was:
Output: It looks like this happens because its loaded the built-in org first, when outshine (require)'s it, and when use-package loads the new one, it overlaps weirdly and breaks a lot of stuff. |
The specific problematic behavior (as mentioned by @Northcode) arises when you load this package using a package manager that doesn't happen to perform the particular optimization that The reason such problematic behavior arises is that this package depends on the
Maybe it won't for
It seems unlikely to me that this package works with Org version 1.0. There must be some minimum version. You could just make the minimum version of Org whatever version was shipped with the minimum version of Emacs that you support; that would be easy enough to find out. |
(if (not (require 'org-sticky-header nil 'noerror))
(ignore (message (format "Cannot load %s" 'org-sticky-header))))As you can see, it just calls Now you're also using Therefore the issue is being caused by Now having said that, why don't you just adjust your init file to fix the problem? e.g. instead of what you currently have: (use-package outshine ;; outshine depends on both outline and org, but will load the built-in org instead of checking if we have a straight.el version downloaded
:straight t
:init
(require 'outshine)
(add-hook 'outline-minor-mode-hook 'outshine-hook-function))
(use-package org
:straight t
:bind
(("C-c a" . org-agenda)
("C-c c" . org-capture)))Do this: (use-package org
:straight t
:bind (("C-c a" . org-agenda)
("C-c c" . org-capture))
:config
(use-package outshine
:straight t
:config
(add-hook 'outline-minor-mode-hook 'outshine-hook-function)))That will probably work fine without any changes to this package or |
Does this mean that you don't intend
In a way, yes; in a way, no. I don't think it's expected or required that packages declare dependencies on built-ins in the headers. As I said, even if I do so, it won't change all the other packages out there, so it seems like an issue that needs to be solved once-and-for-all at the package manager level rather than in individual packages.
I don't know how other package managers behave in this context. I'm aware of package.el, el-get, borg, straight, and one or two others that I can't recall which seem to be mainly one-developer, one-user projects. IMO, alternative package managers should aim to be compatible with package.el rather than asking packages to change for them, even if this means "bug-for-bug compatibility" with package.el. (I realize that it's easy for me to say this, sitting here while you're actually writing an Emacs package manager, but the point remains.) Expecting the thousands of Emacs packages out there to change for you is a losing proposition.
Of course I didn't mean Org 1.0. What I mean is, if the Emacs version is supported, then so is the built-in Org version included with that version of Emacs. AFAIK it's not expected or required to also declare a dependency on that specific built-in version, so if an alternative package manager doesn't work correctly without doing so, it seems like a bug in that package manager. I think the bottom line is, these packages have thousands of downloads over the years, and therefore probably hundreds or thousands of active users. Now some cool, new, alternative package managers are being developed, which is great! But if they don't work with existing packages, that seems like a problem for these new package managers to fix, even if they are ultimately exposing buggy or undefined behavior in package.el. This is the burden of backward compatibility. It can't fairly or practically be pushed onto package authors. |
I regret only that GitHub does not provide me any larger font in which to say NO. Please refer to the Guiding principles section of the README, where the following is listed:
Perhaps I should put that bullet point in bold-face. Or
So, back in 2012 before
And I think we are all very glad that despite the difficulty, Tom went ahead and pushed for a standardized package format. It was a Herculean effort, but well worth it. Now if you look at what I'm proposing, it's not even remotely in the same ballpark in terms of complexity. In fact, I'm not even proposing anything new: the
I think this is just plain wrong. Take a look at what the Emacs Lisp Reference Manual has to say on the So, their example header declares a dependency on the built-in
So... what is the solution you are proposing? Do I have And I'd like to add that this is the first package I've found that has this problem. Most packages do correctly declare dependencies on built-ins.
Sure, it would be—if I were expecting thousands of packages to change. I'm not, though. I'm expecting more like 10 packages to change. Yes,
You're right. Instead of providing a version
Agreed as far as
I believe you go too far. Sure, it's silly for a package manager to ask every package to change its format. But it is entirely reasonable for a package manager to ask 1% of packages to fix existing bugs that happen to manifest as bigger problems when using the new package manager. |
Let's keep this friendly. :)
I am using package.el. :) I am definitely interested in straight.el and Borg, etc, but I'm waiting on them to mature before experimenting and possibly converting. Issues like this are an example of why. ;)
Can you point me to that specification? I'm far from an expert on the Emacs package systems, but I don't recall this requirement, and I don't think most packages do so in practice.
With respect, I'm not sure that example qualifies as specifying that built-ins must be declared as dependencies. You may be right, but that may also be reading too much into a simple example that seems to be about syntax.
Again, that may be reading too much into it. Would a newer version of
I'm not developing a new package manager, nor am I using one, so I'm not proposing any solutions on your part. The suggestion I'm making for the user reporting this issue is to reorder the
Well, in principle you're right, but in practice, grepping for (in Now, what you do with the dependencies you parse out that way is another matter, but simply reading them from the file is straightforward enough. IMO if you want to be as robust and informative as possible, you should probably pursue that option, because otherwise you're depending on the package headers being correct and complete, and obviously that will not always be the case. :)
Well, if there are only 10 packages on MELPA that don't work correctly when installed in infinite combinations and orders with straight.el, that would be great. Perhaps your faith is greater than mine. :) In any case, it's your project, and I'm not telling you how to run it.
Sure, but that won't fix the issue that @Northcode is reporting, because that wouldn't cause a newer, non-built-in version of Org to be downloaded. At least, it shouldn't, right?
Well, as I explained, in this case, IIUC, doing so would not fix this particular problem. (Assuming the problem is indeed that Org 8.x is loaded, then Org 9.x is loaded on top of it, which causes errors.)
If they are actually bugs in the packages that violate the existing package.el specs, sure, it's reasonable--but IMO you're still fighting an uphill battle. e.g. a lot of packages are maintained by authors who rarely check bug reports, and MELPA has no non-maintainer-upload process like Debian does, so those problems are likely to remain for a long time...unless you're offering to take over the maintenance of those packages, and the authors are willing or long-term AFK, and MELPA agrees--so, are you? :) This again raises the question of how many such packages there are, but I'm guessing it's not feasible to test the thousands of MELPA packages in infinite loading combinations and orders, especially when some of them do not declare dependencies on built-ins. By the way, I am definitely no Steve Purcell, but I have reviewed probably 20-30 recipe pull requests on MELPA, from time-to-time, and IME they rarely, if ever, declare dependencies on built-ins. So I think this issue is much more common than you realize. |
Yes, of course. Sorry, I intended my comment to be humorous. Just wanted to make a point :)
I suppose specification is rather a strong word, but I was referring to the documentation of the package system in the Emacs Manual and Emacs Lisp Reference Manual. The question isn't addressed specifically, so is subject to interpretation, but in the absence of a distinction between built-in packages and non-built-in packages I would presume that they are to be treated equivalently.
Answering that question is the purpose of the
That's true, but your comment only applies to the version shipped with Emacs, rather than the version provided on GNU ELPA. My comments concern when another version of a built-in package is also available from one or more package archives (which is true for a few built-in packages, but most importantly Org).
In my opinion, this is a very bad idea. I only made the proposal as a joke. There is no way to tell what the actual dependencies are by parsing the file, for several reasons:
Any steps down that road are definitively in the wrong direction given that there is a specific metadata format designed to provide exactly this information, for exactly the reason that parsing it out of the file is hopeless.
Doing that will fix the problem because yes, it will cause a newer, non-built-in version of Org to be downloaded. That change would be the only thing required to make everything work seamlessly, and I'll happily provide a pull request to that effect.
That's the problem, but it wouldn't happen if
OK, but that's no excuse for not reporting the bugs.
I concede this point. You know more than I. But I don't believe it's an intractable problem, and am perfectly happy to provide pull requests to fix package metadata every once in a while. |
Sorry. Poe's law and all... :)
You might be right, but I'm looking at it from the other perspective: lacking a clear specification in the docs, I fall back on what's commonly done in practice--which IME usually means not declaring dependencies on built-ins. Frankly, I think insisting on this would be a bit of a burden, as well: a package author, having developed a package that definitely works on a certain version of Emacs, the version number of which is obvious, the author would now have to dig out the version number of every built-in library file as well. Also, are we certain that these version numbers are always incremented when changes are made? It wouldn't surprise me if changes are often made to them between Emacs releases without changing the library file's version header. Of course, I haven't researched this, so who knows. :) Anyway, I'm guessing that depending on these library version headers may not be a reliable way to determine compatiblity. (Hopefully I'm wrong, of course.)
I'm a bit confused here, as this implies that cl-lib is intended to be independently upgradable between Emacs releases, but your next comment seems to indicate the opposite...
Do you mean that the version of cl-lib on ELPA is developed separately from the version included with Emacs? If not (and I doubt it is), then the Org is unique in that it is maintained and released separately from Emacs but also merged into Emacs's repo periodically and released with it. This does present some unique issues now and then.
All of those reasons are true, of course. There's only so much we can do with the Emacs package system.
Ok, now this is the crux of the issue. Let's make sure we're on the same page here:
Now I suppose this is a matter of opinion, but as a user, if I load a package that doesn't declare a dependency on a specific version of a package, I wouldn't expect my package manager to automatically download the latest version when there's already a version installed that satisfies the declared dependency. Indeed, I would not want that behavior, as I do not want packages to be automatically upgraded, because that inevitably causes breakage in my config which I then have to fix before I can use Emacs again. Now I can see why some users would prefer that, and why that might be your preferred mode of operation for straight.el, but it's definitely an incompatibility with package.el, the existing Emacs package manager. Therefore this still seems to boil down to straight.el not maintaining backward compatibility with package.el, and pushing that burden onto package maintainers.
I think you are much more knowledgable about how the Emacs package systems work than I am! :) Maybe I have looked at more MELPA packages, who knows. In this case, AFAIK if I add a version-less dependency on Org, it won't do any harm to existing users. But at the same time, I'm reluctant to make changes to workaround incompatible behavior in alternative package managers, especially when it can be fixed by the user by simply adjusting his init file. I've had to do the same thing for my init file, which still uses package.el. In some cases, package loading order does matter. So are we on the same page? Let me know if I've misunderstood anything. Thanks. |
Well, they don't have to figure out what version number is needed, since
I think my example of There may not currently be any package archives that exercise the ability of
Right. And I have seen so many threads of people struggling to get Org installed correctly with
Your summary is correct.
Here are a couple of relevant points which may change your perspective on this behavior:
(Another interesting point is that
Well... yes and no. The fact is, getting Org to work with Of course, the real solution is to not have packages be built-in, and instead have a better package manager so that using packages is as easy as using builtins. But it's taken me six months to convince emacs-devel not to have
OK, fair enough. I personally would place missing dependency information in the same category as other missing metadata (like
OK. If a package doesn't get ever updated, I would consider it dead and not worthy of too much concern. Like I said earlier, there's really no way to generate this metadata if it's not provided.
Yes, I can't think of a case where this could cause any harm.
I object to your use of the word workaround. It implies that Arguably, even though adding a dependency on
Sort of. But, consider: I might want to try And as far as what it looks like in the init-file, suppose that I don't care about Org itself. I only care about (straight-use-package 'outorg)And this wouldn't work, because of the missing dependency information. I'd have to adjust it to: (straight-use-package 'org)
(straight-use-package 'outorg)I basically have to rewrite the dependency information in my init-file. And whenever the user is required to do additional work to use a package, it really implies to me that perhaps the package should be doing this work instead.
Partially. I do agree that missing built-in dependencies is probably more prevalent and not as big of a problem than I made it out to be. But I still think it's worthwhile to fix the issue in popular packages, because it makes the lives of some users more convenient while not causing any problems for the rest. Thanks for your patience. It's very good to discuss these things. Reminds me of the great Friendly discussion about (package-initialize), which is possibly getting close to finished after half a year... ❤️ |
Right, but straight.el handles that case differently: If a built-in version of that dependency already exists, package.el lets it satisfy the unversioned requirement, while straight.el installs the latest version. Of course, we hope that the latest version doesn't break backward compatibility, but since there is no enforcement or even consensus among package authors, this is not guaranteed. Maybe what we're seeing here is sort of a paradigm shift: from versioned, packaged repositories to direct-from-git virtual repositories, and perhaps some conflicts in behavior are inevitable (at least, without a lot more coding to work around them).
That makes sense.
Well, I think MELPA does. For example, IIRC some of my Org packages require Org 9, and they declare a dependency on it, so if the user's built-in version is Org 8.x, package.el should install Org 9 if it's available in a configured repo. It's not very widely used outside of Org though, AFAIK, because typically if a package requires a certain version of a built-in, it will probably declare a dependency on the version of Emacs that includes it rather than the package itself.
That's good to know. It would also help if the org-plus-contrib package were folded into plain org; maybe someday...
That sounds good.
Glad to know that.
Is there an option to make the lockfile automatically?
It's because of those scenarios that I keep
Well, that sounds pretty good, but I'm not sure that's the best way to do it. For a lot of packages that's probably fine, but Org does make backward-incompatible changes somewhat regularly. For example, Org 9 made backward-incompatible changes not only to behavior but to the Org file format; users who didn't read the release notes and run the conversion tool would suffer loss of functionality as e.g. planning lines would become invisible to Org. There are also smaller incompatible changes made more frequently in minor releases. So if I were a user on a version of Org, and then started using straight.el, I would definitely not want Org to be upgraded to the current release automatically.
Well, that's interesting, and the, shall we say, lassiez-faire style that the Emacs package community tends to develop a lot of non-core or non-library packages gets away with that a lot of the time. But there are plenty of counterexamples, such as Org, Magit (which once required a certain version of git upon upgrade, which would then break magit until you manually installed a new version of git), dash.el (which plans to make backward-incompatible changes soon), etc. I'm glad that it works a lot of the time, but I think trouble is inevitable.
Well, as I explained, Org is a particularly strong example of a package that should only be upgraded carefully. :)
Well, this might be too nit-picky to bother talking about, but I'm not sure I understand or agree exactly here. The only problem I've ever had with Org and package.el is caused by there being both And as you explained, straight.el is not accounting for version numbers, so I'm not sure it's necessarily a fair comparison between it and package.el. IMO straight.el ignores version numbers at its peril. ;) Luckily, it works most of the time, but it will inevitably fail in some cases, because the version numbers are there for a reason.
Well, you probably don't want to go down that rabbit hole here, but I'm not sure what you mean about not having packages be built-in. I don't think it would be an improvement to distribute built-ins separately in most cases. There might be a few that would be good to split out, but stuff like cl-lib, seq, map? That doesn't seem like a good idea to me.
Yeah, I saw that thread yesterday but I didn't read all of it. I guess the point is to not automatically use package.el, so that alternative package managers can be used?
Not sure exactly what you mean here. package.el uses it, MELPA uses it, Borg/epkg use it, etc.
Well, they are concerns for users who use them. :) As the EmacsWiki/MELPA discussion has shown, there are a lot of rarely-updated packages that are widely used. Emacs packages also have more of a tendency to get to a virtually-done state than other systems, to the point where they rarely need updates (something I appreciate!).
Yeah, it would be quite an undertaking to do some kind of recursive static analysis across packages. Theoretically possible I guess, but not something I want to work on! :)
I think I disagree slightly here. Either the specification requires something or it doesn't; either it permits something or it doesn't. If straight.el adds additional requirements, I think that's a case of it being incompatible with the specification. As an analogy, consider HTML parsers (an enormous world of pain). Browsers go to extreme length to handle poorly-formed documents. Obviously I'm not advocating the equivalent here, but if a browser were to add an additional requirement on top of the HTML spec, that wouldn't be a case of the browser requiring stricter compliance with the spec, but adding to and changing the spec in an incompatible way. The result would be that people would stop using that browser, not that web sites would all make changes to accomodate it. (Of course, you could cite IE and its IE-specific features as a counter-example, but I'm sure you see my point.)
Well, in this case, it is specifically necessary for straight.el, because nothing else is needing the change to be made. :) AFAIK the general expectation is that packages need not declare dependencies on built-ins unless they differ from the version included with the version of Emacs they are intended to be used with (in which case it's arguable which version of Emacs they are intended to be used with, but I digress). So this still seems to me like a case of straight.el asking packages to change to suit its backward-incompatible behavior.
If you think that all packages should declare dependencies on all built-in libraries, sure. If not, then no. :)
I don't understand why that would be the case. In that case, Outorg would
As far as I know, that would work fine.
Ideally the web of dependencies would be accurate and comprehensive, and users could attempt to load packages in any order, and they would always be resolved correctly. Hopefully that will be achieved someday in the Emacs package ecosystem. And maybe straight.el or similar projects will lead the way.
That seems reasonable. I don't mind adding a versionless dependency to the headers. Although I confess, with all the packages I maintain on MELPA, if you start asking me to do this for all of them, I may become annoyed. ;) That is to say, if the community were to settle on straight.el or some other package manager as the standard one, I would gladly adjust my packages to comply with its requirements; but I'm not eager to support a multitude of them, each with their own quirks. I think one of the strengths of Emacs and its packages is that they are relatively stable and backward-compatible, and so I think new package managers should strive to be as compatible as possible with the standard package manager, even when that means compatibility with irritating quirks in package.el.
Yes, and thanks to you as well. I hope that projects like yours will lead the way to improving the Emacs package system. It takes enthusiasm and dedication to see a project like straight.el through. I hope that in the future the community can either bring package.el up to speed or standardize on another package manager. Until then, issues like this will persist. |
I hadn't considered that because it seems like it would be annoying. You couldn't have local modifications in your repositories, because saving a lockfile means first getting all of your local repositories into states that can be replicated on other machines (for reproducibility).
Yes.
I thought the main reason the two were separate was that it takes much longer to byte-compile all of the contrib files, and not everyone wants to do that. So it seems doubtful to me that the two will (or should) merge.
But if you were switching to Consider also the fact that
But the trouble is not really trouble. One must ask, when does the trouble arise? And the answer is, when you upgrade your packages. Because with
The problems I was thinking of were like jwiegley/use-package#319.
But to reiterate, the only time when version numbers will make a difference for
I agree that Not a single one of these could conceivably be considered as part of the category of standard-library packages like I found it interesting that XEmacs did this, once upon a time.
No,
They don't use the dependencies on built-ins, though. That's the part that's under discussion here.
Well, those packages are doomed to die a slow death as functions are deprecated and packaging requirements are modified. Fine by me; if people really care then somebody will become the new maintainer.
Actually, very much not theoretically possible. Determining whether Elisp code is going to require a feature is equivalent to the halting problem. And then there's the issue that it's impossible in general to correctly guess what package provides any given feature. And even this secondary problem is not solvable even in theory, since multiple different packages could provide different versions of the same feature (e.g.
This point is reasonable. I'd however argue that our situation here is better because the average Emacs user is more resourceful than the average web browser user, and the average Emacs package maintainer is more resourceful than the average web site maintainer. So we can expect to get things working for everyone without quite so many hacks.
Well... I should clarify what I mean by "broken". From the perspective of a
It should be clarified that at no point is So I assume what you mean is that if the But your suggestion gave me an idea about how to change the result of missing built-in dependencies from subtle undefined behavior to an explicit error: radian-software/straight.el#236.
Fair enough. Given that this change benefits me primarily, I'd be happy to provide the pull requests for other packages that people may find lacking dependency information.
OK, I think this is just an irreducible difference in philosophy, since I believe the opposite. But that's alright, we can agree to disagree. |
So after a lockfile is set up, the user can't make local changes?
For local building, a Makefile target can be used to select which set of files to build. For installations from repos, the contrib files should be put into a separate package. Having two packages which install the same set of files has caused so many man-hours of wasted problem solving...
Okay, so that's something that straight.el users will just have to deal with manually, I guess.
Yes, that's why I always advocate doing that. I think doing otherwise is madness. :) Otherwise, with a substantial number of packages, every time you install your Emacs config on a new system, or every time you upgrade the set of packages on one system, you're going to have a unique set of incompatibilities to solve before you can use Emacs again.
Well, actually all of those packages are in version control, they're just in repos out of the user's control. :)
IIUC they can also change when setting up on a new system--unless the user has set up a lockfile, but IIUC that precludes customization, so... I confess that I'm getting a bit confused now. The simplicity of using package.el with
Are you sure? What about this scenario:
Sure, so maybe some of them will gradually be moved to ELPA or a separate package (of course some distros already split some of them into separate binary packages).
Without adding
Are you sure? For example, AFAIK package.el will allow the built-in version of Org to satisfy a declared dependency in the headers.
It's not fine by their users, though. And, surprisingly, a lot of Emacs users are not elisp programmers, package developers, etc. There are a lot of Emacs users who don't customize their init files, or who do so only by pasting snippets they find online. We shouldn't pull the rug out from under these users. I'm talking about packages which have stabilized to the point where they rarely, if ever, need updates. You seem to be proposing to invalidate those packages because of package headers, not any actual breakage in the package's code. That's not okay.
To do so perfectly, sure. But there are only so many functions that load code in Emacs. It's not necessary to execute a package's code to determine what it may eventually load.
It's true that some packages contain files that don't have the same name as the package itself, but that doesn't mean that some basic checks would be useless. Nor does it mean that they would be useful enough to spend time on, haha. But I would again point to
We're part of a larger community and ecosystem. As the more practiced participants, we have a duty as stewards to be good caretakers for those participants who are simply users of it. That means we should avoid breaking things without a very good reason (e.g. security, safety, or really old code that virtually no one uses and would be a significant burden to maintain compatibility with). By the way, some of these non-elisp-programmer, "simple users" are actually people like scientists, statisticians, software developers in other languages, writers, etc. Just because they don't have expertise in the specific domain of Emacs or Elisp or Emacs packages doesn't mean that they are unintelligent or incapable--it means that they have other domain expertise and are busy using it. If we break the code that they are using and have been using for years, and force them to devote time to fixing problems in Emacs or finding alternative solutions, we are doing them a diservice, and we are harming the Emacs community in the long-term. For myself, one of the reasons I use Emacs is that, even as surrounding software in the FOSS community rapidly changes and breaks incessantly, Emacs doesn't. We should be careful not to mess with this. So this is why, even as I applaud your work on improving package management, I caution you to do so in a way that provides long-term stability and compatibility, and considers the needs of all users. This is necessary if you want your alternative to be widely useful rather than for a niche set of users (Emacs users already being a niche set of computer users).
This is a bit confusing to me. Does straight.el not support loading built-in packages? What about ones which are only available as built-ins?
Sorry, I'm confused again: you mean if the user does
Sorry, I don't understand. What I'm saying is, if straight.el comes across a package that depends on
Sure, if you have different goals for straight.el, that's up to you. I'm not sure exactly what they are, but if you are aiming to eventually replace package.el, I think it may be necessary to ensure closer compatibility with it. But I'm sure emacs-devel will take care of ensuring that. ;) |
Not quite. When writing a lockfile, all local changes must be reconciled (by the user, interactively, with the aid of The correct mental model is that your configuration's behavior is specified by (init file + lockfile + arbitrary local changes). And on a new machine, the behavior will be (init file + lockfile). So, you can only be sure that behavior won't change on a new machine if you first reconcile all the local changes. Since I want to discourage people building up large quantities of local changes on one machine (since it introduces the possibility for breakage), I have
This is obvious in hindsight and I wholeheartedly endorse your suggestion. Just have package
Manual work here happens whenever you change from one package manager to another package manager, unless both package managers store their metadata in the same format on disk. (It might be possible/interesting to create a tool in
One main reason I created
Right, lockfile and customization are not mutually exclusive except that
But then consider what this "simplicity" buys you when you want to contribute a patch upstream to one of your packages.
But I want to! ;)
You might be right. I don't know what happens in that situation. In any case, existing packages aren't upgraded by
Yep, that has happened already to some of the obsolete packages, and I think it's a great move.
Wrong, it is no longer necessary to have
You are right; what I meant was that no current software relies on dependencies on built-ins. That is, if they're missing, then the behavior of current software doesn't change noticeably, even though the information may be technically used.
OK, this is a very fair and reasonable argument. I do agree that we want things to work out of the box as often as possible, for the benefit of these users. But I still refuse to use heuristics to guess dependencies. So how about the following solution, instead: Introduce a new, community-maintained recipe repository that provides custom recipes for the few packages which
so that these packages can work out of the box with I wouldn't expect such a recipe repository to be a big maintenance burden, because the intersection of the three categories above is pretty darn small, and the fact that the packages are unmaintained means, of course, that the recipes don't need to be updated! And this is all assuming, of course, that we can't find an existing source of metadata that works well enough (maybe el-get?). Incidentally, this is rather similar to how I added support for Microsoft Windows to
I think we mean different things by "load". When I say load, I mean evaluate a file of Lisp code. So in this sense,
In light of what I've said above, I'm not sure in which sense you are saying "load". But I am guessing that, regardless of the sense in which you said "load", the answer is no, since
And the problem with this suggestion is that
We shall see, indeed... |
Thanks, that makes sense. It's actually very similar to the model I use, where my config's behavior is specified by
Indeed. :) Hopefully someday...
I see, thanks.
This is curious to me. If you don't mind me asking, why do you want to avoid that? I like that I have all my config's source code, including all packages, in my own repos, and that I don't depend on MELPA or ELPA or any GitHub repo being available to reproduce my config.
Well, I've heard that Borg is specifically designed to address this problem. Other than that, I do send PRs sometimes, and then when the package is updated, I just update it and overwrite any local changes I may have made.
And you may. :) I am definitely interested, but honestly I don't feel like I have the energy to learn a new package manager and convert my existing config anytime soon. It will require some learning and adjustment, and what I have now works very well for me. But I'm glad you're working on improving things.
Well now that is interesting. I'm pretty sure that I would have experienced breakage like this, because it already happens to me with MELPA and package.el sometimes. But I tend to avoid upgrading packages until I need to, whereas it seems that many users always upgrade everything. Whether you upgrade as necessary or live on the bleeding edge, you have to deal with breakage of one kind or another.
Ah, I see. That sounds good.
Yeah, I don't necessarily think it would be good or useful enough to bother with, either.
That's an interesting idea. I guess whether it's worth it it would depend on how many users straight.el has and how many of them use those packages. I also wonder how existing efforts fit into the picture, like MELPA, emacsmirror, emacsattic, etc. It sounds a little bit like Gentoo/Arch/Nix/Guix but for Emacs packages. But then I also wonder how the existing package recipe system fits in. I'm not expert enough on all that, but it's definitely an interesting idea.
Now I understand. Thanks. |
I dislike checking other people's code into my repositories for the same reason that I dislike checking build products into my repositories. It solves some problems, but it's just so ugly :) Plus, embedded packages are strictly inferior to individual repositories for development. (Check out old revisions, look at the logs, compute diffs and patches, send pull requests, merge changes...) In my experience, whenever someone who uses
Yes, that is a minor disadvantage of my way. I say minor because it's never caused any problems for me. The flexibility (including being able to implement fully lazy installation where packages are installed as autoloads are triggered, as well as use the full power of Git to move between package revisions, which I view as essential for development) outweighs the potential trouble, for me.
Yes, and so is
I figure that lack of users and/or usage is a self-correcting problem. If people don't use the problematic packages, then those packages don't need to have recipes in the repository. Contrariwise, all it takes for a package to get fixed is for one person to say
The role of MELPA is reducing the number of recipes which need to be maintained from 100% to 20%. The role of EmacsMirror is reducing the number from 20% to 5%. The only packages that need custom recipes here is the few packages that are (1) not in MELPA and (2) too complicated for the default EmacsMirror packaging to work out of the box. I.e. the packages which don't already have a perfectly good recipe in some other recipe repository. Again I think of el-get which may reduce the number of problem cases to an even smaller number.
It's actually very simple. The variable Just to clarify, this would require absolutely no additional infrastructure in |
In reference to: radian-software/straight.el#233
Both outorg and outshine appear to be missing a bunch of dependency declarations.
Outorg currently specifies:
;; Package-Requires: ((emacs "24.4"))However it actually requires:
org,org-watchdoc, outline and emacs.Outshine currently specifies:
;; Package-Requires: ((outorg "2.0") (cl-lib "0.5"))It actually requires:
cl, cl-lib, emacs, imenu, navi-mode, org, outline & outorgThis causes breakage if they are not installed or outorg is loaded before any of its dependencies not specified in the package, as it may load an incorrect version (like using built-in org instead of org installed from git or melpa) or just break because they arent installed.
The text was updated successfully, but these errors were encountered: