I agree that subtrees are usually preferable; however, there are many
projects using submodules (perhaps introduced before subtrees were merged
into git master or subsequently popularized.) A ban on submodules would be
shortsighted dogmatism. Furthermore, there are several reasons *to* use
submodules, even if the interface is complex and it doesn't work for *some* use
cases. Even if it were an option, It wouldn't make any sense to enforce
because of the potential to break otherwise entirely
legitimate repositories. (Subtrees wouldn't help over submodules anyway, in
your case.)
Submodules are bad, but petition the git maintainers, not LR ;)
This whole tangential mess is a because I don't believe LR should add any
kind of artificial restrictions on how one *builds* their project;
additionally I'm not entirely sure about distribution mandates such as
a "no-downloads-at-build-time" policy
which are occasionally necessary when one needs to, for example, download
libraries conditional to a particular environment unknown beforehand. It
seems that, if you have a policy restricting these kinds of libraries, you
should either look hard at why that's an absolute policy or find another
library to use.
On Sun, Sep 9, 2012 at 11:14 PM, Alexander Gladysh <aglad...@gmail.com>wrote:
> On Sun, Sep 9, 2012 at 8:00 PM, Hisham <h...@hisham.hm> wrote:
> > On Sun, Sep 9, 2012 at 10:52 AM, Alexander Gladysh <aglad...@gmail.com>
> wrote:
> >> On Sat, Sep 8, 2012 at 6:13 AM, Hisham <h...@hisham.hm> wrote:
> >>> On Fri, Sep 7, 2012 at 9:59 AM, Alexander Gladysh <aglad...@gmail.com>
> wrote:
> >>>> On Sun, Sep 2, 2012 at 12:54 AM, Alexander Gladysh <
> aglad...@gmail.com> 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
> Luarocks-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/luarocks-developers
>
------------------------------------------------------------------------------
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
Luarocks-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/luarocks-developers
