-
-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Building stable packages using VC tags #7
Comments
Having used Ruby, Rails, and Bundler a fair amount recently, I think the Ruby world essentially has it right on this issue. My recommendation is to copy them shamelessly, since mixing Git snapshots with stable packages is relatively painless in that world. |
I think it would be best to add support for prerelease versions to package.el itself. It may still make sense to keep them in separate repositories, (rubygems and maven both do this) but you want the default to be only to pull in releases; snapshots should only come in when explicitly requested. |
Hey, @technomancy, what could |
how to have a name that's hard to search for... |
@purcell Unfortunately I think the nix approach can't really be applied to Emacs right now. Isolation of code is really impossible in elisp, so the notion of immutable trees of dependencies really can't be applied. So the primary lesson is just that the lack of a module system is a really crippling flaw. |
I especially like Bundler's ability to list dependency versions like
Re: Nix: it's a neat take on packaging. |
I think the main thing that's actually feasible that's missing is the ability to separate out prerelease versions from actual releases. Rubygems does a decent job at this; it will only look for prerelease versions if the user explicitly asks for it. I would also like the ability to specify exact version dependencies instead of minimum dependencies, but I think that would complicate the dependency resolution logic by several orders of magnitude, and I'm not sure it's worth it given that elisp isn't used for production software. (so repeatability is not of paramount importance) |
so, can we just add a configuration tag here called |
@milkypostman You mean build both versions into the same archive? |
no, i mean, just build two packages each run. and have two package archives. On Mon, Jun 17, 2013 at 1:08 PM, Steve Purcell notifications@github.comwrote:
|
Yeah, to accomplish a dual build without a ton of hackery, I think we should basically run the whole build top-down in two different modes, setting a different output dir for each using the current I'm not sure about "either a branch name or a tag regex" -- the tag regex I can understand, but a branch name isn't sufficient to identify both a specific commit and a name for the release, since any number of commits can be made on a branch. Ideally we'd have a standard tag regex, because otherwise we'd presumably end up repeating a very similar pattern in all the recipes. |
but isn't is possible that someone could just consider a branch to On Mon, Jun 17, 2013 at 1:38 PM, Steve Purcell notifications@github.comwrote:
|
OK lets start with melpa/powerline I have tagged a version 2.2. Lets assume that the default way to do this is a regex that is |
Yes, ideally we'd want to support any versions supported by So a simple first step would be that we'd add a I imagine we'll need per-SCM functions for querying tags, and we'll also need to have per-SCM code for checking out specific tags: in the case of subversion, for example, this will likely require the inclusion of additional information about the repo structure in the recipe -- knowing a URL like "...foo/bar/trunk" is not sufficient to locate tagged versions in that same repo. Starting with git is a reasonable first step. |
couldn't we just assume for the time being that if we can find a tag in the for svn, couldn't we assume if the repo ends with On Tue, Jun 18, 2013 at 6:54 AM, Steve Purcell notifications@github.comwrote:
|
That would be nice, but it's not a safe assumption. For example, if an Emacs mode is part of a larger code repository (think Erlang), then does a repo-wide tag imply that the Emacs mode has that version? Usually not. So a safe scheme (at least initially) would be to opt in recipes one by one, or use some heuristic, e.g. whether the recipe includes files at the top level of the repo. Similarly, the suggested heuristic for subversion tags based on common practice is worthwhile, but it won't be the full story. |
dang you're always right! On Tue, Jun 18, 2013 at 7:47 AM, Steve Purcell notifications@github.comwrote:
|
Nope, my wife is always right. |
@technomancy Very complex indeed, but you are wrong about Elisp not being used in production. I use Emacs everyday for work. If I for some reason remove my ELPA bundle and install again, I most likely will get new versions installed, which may break my Emacs installation. This has actually happend to me a couple of times. Specially fun spending halv a day fixing that when you are soaked at work. If we ignore the complexity I think MELPA should create one build per VC-tag. The problem with this is that package.el would either need to support multiple versions (see http://bzr.savannah.gnu.org/lh/emacs/emacs-24/annotate/head:/lisp/emacs-lisp/package.el#L153) or send a list of all packages including version to the mirror before syncing the archive contents. I would very much like to be able to add support for a |
Well, more generally you'd want a |
Yes, that would have been a simple solution. |
soooo http://hiddencameras.milkbox.net/ only git and only packages that have a tag. i need @purcell to school me on this sys admin stuff. it always feels like a hack, so now we have two sets of service scripts. |
@milkypostman Yeah, we should perhaps even have 2 separate build users... Great that you set that stuff up so we can see what it produces. Looks pretty good, doesn't it? One immediate issue I see is the one that I foresaw about elisp hosted inside the repo for a bigger project: A nice way to handle this might be to support upstream version tags in the form "package-name-1.2", so that Also, the Relatedly, @tarsius had mentioned that we should probably provide a way to exclude pre-release tags, and I think a recipe mechanism something like |
In descending order of popularity, the other fetchers we'll need to modify appear to be: |
For a first run it doesn't look so bad. Is there a problem with using the main repo version for the package version for large packages? It makes sense to me that when a new Scala version is released that the new Scala mode package have a corresponding version. |
Also darcs before cvs man!
|
The problem is that the elisp is often versioned separately with a |
Oh yeah derp. Good point.
|
Why not just refuse to include packages in the tagged repo if they don't either 0) tag specifically for the elisp lib or 1) provide prefix under which elisp-specific tags can be found? |
@technomancy That wouldn't cover the case where an elisp-only repo has its lisp in a "src" or "lisp" subdir: the entire repo would be tagged, not just the elisp dir. But yes, the tag prefix idea you mention is pretty much what I suggested in my earlier comment, and seems like a good way to go. |
Closing this. I think we are doing this now. We can file further issues in the future if we need to track it. |
Fix Package-Requires
When a recipe specifies an upstream source with numeric tags (or perhaps branches), we can use that info to build stable packages.
package.el
won't easily handle coexistence of stable and snapshot packages in the same package archive, sincepackage-list-packages
(currently) only shows the highest available version number of a package, andpackage.el
provides no way to selectively install a version1.4
instead of20120406
.Renaming snapshot packages to add a
-snapshot
suffix is an option, but might wreak havoc with inter-package dependencies;foo-snapshot
packages would not satisfy a dependency uponfoo
, for example, and so dependency names might need to be updated.The alternative plan we've discussed is to provide two parallel archives, each with separate URLs and contents; one would contain snapshot packages, and the other would contain stable packages. In reality, though, many users would want to combine packages from both archives, and so machinery like that provided by
melpa.el
would be required in order to selectively install stable package versions when snapshots are also available.The text was updated successfully, but these errors were encountered: