[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installe
From: |
Philip Kaludercic |
Subject: |
Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS |
Date: |
Wed, 26 Oct 2022 07:19:30 +0000 |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Philip Kaludercic [2022-10-24 20:34:31] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Philip Kaludercic [2022-10-24 15:35:42] wrote:
>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>>>>> One thing I recently noticed are :url entries of the form
>>>>>> "bzr::https://bzr.savannah.gnu.org/r/org-edna-el"
>>>>>>
>>>>>> or
>>>>>>
>>>>>> "hg::https://hg.savannah.nongnu.org/hgweb/enwc/"
>>>>>>
>>>>>> How are these handled? I couldn't find anything specific to this in
>>>>>> elpa-admin.el. Is this a Git feature?
>>>>>
>>>>> Yes, it's a Git feature. Git will use the `git-remote-FOO` extension to
>>>>> access those repositories. In my experience it tends not to work super
>>>>> reliably and those extensions aren't installed in `elpa.gnu.org` so we
>>>>> don't auto-update from those repositories.
>>>>
>>>> That also means that these repositories should either be filtered out
>>>> from elpa-packages.eld or the format should indicate that VC backend is
>>>> used.
>>>
>>> The current format will work for those users who have the corresponding
>>> `git-remote-<BACKEND>` adapter installed, but yes I guess we need to
>>> refine a bit what we mean by a "URL". Currently it's actually not
>>> really a URL but the "name" of a Git repository, tho it happens to look
>>> very much like a URL.
>>>
>>> Maybe we could use something like
>>>
>>> `:url (hg "https://hg.savannah.nongnu.org/hgweb/enwc/")`
>>
>> Looks fine in principle, Would this only apply to non-Git repositories
>> that just happen to look like a URL?
>
> All non-Git repositories have such a URL, AFAIK, but yes, we'd use that
> for all non-Git repositories (all 3 of them :-).
Another possibility would be to add another property like :vc-backend.
We could also use the opportunity to extend the "elpa-packages.eld"
format (not necessarily "elpa-packages" itself) to have some metadata
like a format-version or default backend.
- Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, (continued)
- Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Philip Kaludercic, 2022/10/23
- Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Stefan Monnier, 2022/10/24
- Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Philip Kaludercic, 2022/10/24
- Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Stefan Monnier, 2022/10/24
- Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Philip Kaludercic, 2022/10/24
- Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Stefan Monnier, 2022/10/24
- Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS,
Philip Kaludercic <=
- Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Tim Cross, 2022/10/09
Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Stefan Monnier, 2022/10/08
Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Tim Cross, 2022/10/08
Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Richard Stallman, 2022/10/10
Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS, Philip Kaludercic, 2022/10/15