Am 21.12.2015 um 13:15 schröbte Philipp Janda:
> Am 21.12.2015 um 12:14 schröbte Geoff Leyland:
>>> On 21/12/2015, at 11:26 pm, Daurnimator <q...@daurnimator.com> wrote:
>>>
>>> On 21 December 2015 at 19:37, Geoff Leyland <geoff_leyl...@fastmail.fm>
>>> wrote:
>>>> 2) There doesn't seem to be a protocol on which luarocks will talk to a
>>>> *private* repository on bitbucket.
>>>> git:// seems to be unauthenticated, so doesn't really work for private
>>>> repositories.
>>>> Luarocks doesn't seem to understand ssh:// urls.
>>>> https:// nearly gets there: I can get a zip of the repository with:
>>>>
>>>> source = { url =
>>>> "https://<username>:<password>@bitbucket.org/<username>/<repo>/get/master.zip"
>>>> }
>>>>
>>>> But the top level directory of the zip is unhelpfully named
>>>> "<repo>-<hash>", rather than the "<repo>-master" you get from github.
>>>> This means that you can't set source.dir to the name of this directory
>>>> (since every time you commit the new hash you... change the hash of the
>>>> head).
>>>
>>> And you're sure "master" doesn't work?
>>> Usually websites just feed that piece of the url directly to git: on
>>> e.g. github you can use <hash> or `master` or `master^` or any other
>>> git commit-ish
>>
>> I really hope master does work, but where should I be using "master"?
>>
>> In the above, I ask for "master.zip", (or tar.gz) and get "master.zip", but
>> master.zip contains one directory: "<username>-<repo>-<hash>". That is, it
>> helpfully converted my commit-ish into an actual commit hash. You can see
>> what they're thinking, I guess: that top level directory name is unique
>> within bitbucket, but it's not helping me. As I said, if you ask github for
>> master.zip, the top-level directory is named "<repo>-master".
>>
>> At the moment the only solution I can imagine (apart from giving up
>> on bitbucket) is to patch luarocks so that maybe source.dir can be a
>> pattern (oh, hey, can it already?), or maybe if source.dir is blank
>> and there's only one top-level directory in the zip, then that's
>> where it looks for what it's looking for. I haven't actually looked
>> at the relevant bit of the luarocks source yet, so I don't know how
>> tricky that might be.
>
> That shouldn't be too hard, the relevant bits are already there. The
> function you'd want to use is `fetch.find_base_dir()` in
> `src/luarocks/fetch.lua`, and the place you need to edit is in
> `fetch.get_sources()` (same file) right after the `fs.unpack_archive()`
> call.
Two other things: This would probably be a welcome addition to LuaRocks3
(unfortunately the change isn't backwards compatible), and you can
implement your changes in a custom fetcher module and provide that as a
rock as well (so you don't have to run a patched LuaRocks). Have a look
at the files in `src/luarocks/fetch/`.
Philipp
------------------------------------------------------------------------------
_______________________________________________
Luarocks-developers mailing list
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
