On 22 March 2016 at 16:35, Stefano <phd.s...@gmail.com> wrote: > On 21 March 2016 at 20:56, Hisham <h...@hisham.hm> wrote: >> On 21 March 2016 at 16:40, Stefano <phd.s...@gmail.com> wrote: >> > On 20 March 2016 at 02:44, Hisham <h...@hisham.hm> wrote: >> It is possible to detect all these non-real-conflict cases >> mechanically: for every conflicting name, if the rock contains a >> directory with the name of a module (e.g. copas/ ) but this directory >> does not contain init.lua, then it's not a conflict, it's just the >> part of a longer path (copas/timer.lua -> copas.timer). This will work >> for all cases listed above, and it won't be necessary to maintain a >> list anymore. > > > That's right, I was worrying about hypothetical cases like zeromq.ffi and > zeromq.timer unrelated and written by different authors (with no "main" > module zeromq). > But indeed that would work anyway, I'll implement it this way if no > complications arise.
Cool, I really think this will work. >> >> On supporting external dependencies: this seems logistically >> >> complicated (especially given multiple platforms). How do you envision >> >> doing it? I guess this could be more easily achievable with support >> >> from module authors themseves (e.g. if in a future rockspec format we >> >> allowed them to point to native packages that would fulfill the >> >> dependencies — but then again, how to do this on Windows). >> > >> > >> > Very briefly, the plan is as follows: have a simple script for Linux/OSX >> > (bash only) and Windows (cmd only) that builds the sources. >> >> I got confused at this point: building what, the external dependencies >> themselves? > > > Yes, the C dynamic libraries, like libsqlite3. Oh, wow, this is way more ambitious! Rules for building arbitrary C dynamic libraries is not something I'd like to add to the LuaRocks specification (in principle I'd like to keep the scope of the project restricted rather than let it grow into a general-purpose package manager). But I did write a package manager for building arbitrary programs+libraries in the past (GoboLinux Compile - specs here: http://recipes.gobolinux.org ) and even got it running on Linux, OSX and Cygwin. Not something I'd like to venture into again, myself, as I know it is a lot of work. :) >> If there was a way to map external dependencies to OS packages in >> rockspecs (or an off-rockspec master list), would that be enough, >> maybe? (e.g. if we have a list saying that whenever OPENSSL is >> required as an external dependency in a rockspec, this means the >> openssl package in Homebrew, the libssl-dev package in Debian, etc. — >> side question: could Nuget be the "OS package manager" for this >> purpose on Windows?) > > > I'm not sure that relying on "external" package managers would work well > enough. > Different Linux distros have different managers, Windows would be > problematic, end even on OSX plenty of people don't use homebrew nor ports. Yes, I have the same doubts. But _maybe_ it could work well enough for a relatively large number of people with way less work involved. That's why the idea sits at the back of my head. > Plus it would break the portable aspect of ULua (across folders and OS), I > very much prefer to bundle-in everything needed, the OSX way. I see. Linux users would probably prefer to use the system's external dependencies, though. There's no way to please everybody with a single approach, that's for sure. I'm wondering if ULua could use the bundled packages and LuaRocks could reuse those on Windows someway but stick to the OS packages everywhere else... -- Hisham ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140 _______________________________________________ Luarocks-developers mailing list Luarocks-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/luarocks-developers
