On Sun, Sep 9, 2012 at 8:00 PM, Hisham <[email protected]> wrote:
> On Sun, Sep 9, 2012 at 10:52 AM, Alexander Gladysh <[email protected]> wrote:
>> On Sat, Sep 8, 2012 at 6:13 AM, Hisham <[email protected]> wrote:
>>> On Fri, Sep 7, 2012 at 9:59 AM, Alexander Gladysh <[email protected]> 
>>> wrote:
>>>> On Sun, Sep 2, 2012 at 12:54 AM, Alexander Gladysh <[email protected]> 
>>>> wrote:

>> We have a strict policy that requires us to store all foreign LR
>> dependencies locally (which paid off during recent outage BTW). This
>> policy makes lua-html-parser rock unusable for us, since we *can't*
>> store its .src.rock in a way that it will be self-contained.
>
> Understood. That is indeed a problem.
>
>>  Worse,
>> apparently, we can't know now if *any* cmake-enabled .src.rock we have
>> is self-contained. The only option we have is to forbid cmake rock
>> dependencies.
>>
>> So, would it be possible to:
>>
>> 1) Add a config setting that will disable cmake's feature that downloads 
>> code?
>> 2) Force such rocks to be self-contained somehow upon acceptance to the LR 
>> repo?
>> 3) Add a config setting that will disable cmake altogether (while
>> keeping cmake in the system)?
>> 4) Clearly mark build system in the rocks html index, for each rockspec?

> This is not a problem specific to cmake. Nothing stops one from
> writing a Makefile that runs git or wget, too. The only rockspecs you
> can be "statically sure" that don't pull anything at build-time are
> the builtin ones.

Well, yes, but cmake promotes that behaviour by "understanding"
submodules. Still, non-builtin rockspecs are often a PITA.

> I try to make this unnecessary for rock writers, by supporting various
> download systems. From this situation, I guess we need to add support
> for git submodules.

I, personally, believe that Git submodules are evil, broken, and
should not be used by anyone. Subtrees are much better.

Here is a SO question with my submodule woes that are a basis for my
position: http://stackoverflow.com/questions/1596822/git-submodules-workflow

So, personally, I would be happy to see submodules unconditionally
banned in LR. But, since this is not something that in scope for LR to
set policy, yes, please, do add support for submodules in the builtin
mode.

> And maybe a "no-downloads-at-build-time" policy
> for .src.rock files from the main repo should be established.

Would be great!

Alexander.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Luarocks-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/luarocks-developers

Reply via email to