Skip to content
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

Support for finding projects in tarballs #57

Closed
wants to merge 1 commit into from

Conversation

vseloved
Copy link

@vseloved vseloved commented Apr 4, 2012

Hi Xach,

For deployment of my internal projects I needed a way to distribute custom libraries as a single file a la java jars (the obvious choice being tarballs). As quicklisp has all the pieces needed for that, I've just re-used them and added a separate searcher function, that searches in ASDF:CENTRAL-REGISTRY dirs for tarballs and unpacks them in the same dir.

I though that this may be an interesting addition to quicklisp-client. The current implementation is more of a proof-of-concept sort, as it doesn't involve ASDF source registry (should it?) and unpacks the tarballs in-place (probably, there should be a more robust variant). If you have any ideas, how to improve that, I'm ready to implement them.

Vsevolod

@quicklisp
Copy link
Owner

I don't quite understand the use-case. Is this for when the tarballs are local rather than available via HTTP?

And there's no formal index, just an ad-hoc contents-of-a-directory thing?

@vseloved
Copy link
Author

vseloved commented Apr 4, 2012

Yes, when the tarballs are local: as the user doesn't have control over what's in the repository, this can be one of the ways to override some system from upstream. For example, if you have local changes, but you don't want to distribute them as source tree.

It may also be similar to local projects, but I understand (or, maybe, misunderstand) local projects as more suited for development environment, not for production deployment.

Yes, no index.

@quicklisp
Copy link
Owner

This is an interesting idea, but I don't think it should be part of Quicklisp. It would be better as a separate project.

@quicklisp quicklisp closed this Apr 4, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants