Experimental branch that fetches and builds luajit about lupa HOT 7 CLOSED

why can't this be an additional thing that the installation tries?

from lupa.

It could, and there's no reason I couldn't make a variant of this branch
that adds it as yet another install option. I'd be happy to.

But the biggest part of why I'm doing this is to battle installation
complexity. Currently we are trying to support several versions of Lua and
LuaJIT (some of which fail the unit tests), finding them either globally
installed or locally, building with Cython if available but falling back if
it's not. That's an almost catastrophically large test surface that it
doesn't seem like we have the infrastructure or manpower to maintain. And
of course, it's demonstratably fragile because a repo that builds perfectly
in one environment may fail completely on another (supposedly supported)
environment.

But people like/need flexibility, so I have no intention of pushing any
sort of pared-down version as a candidate for master. All I want to have is
a nice, simplified branch that installs in as consistent a manner as
possible across a wide set of platforms.

tl;dr I'd love to backport the fetch-and-install to the existing complex
install system when I'm done, but that's actually not the point of this
branch, just a means to its end.
On Jun 27, 2013 12:00 AM, "scoder" [email protected] wrote:

why can't this be an additional thing that the installation tries?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-20100556
.

from lupa.

Since I'm still have issues with install consistency due to Cython vs. Not, I'm going to do as the Cython docs recommend and completely strip Cython awareness out of setup.py. This makes it developer responsibility to recompile and commit _lupa.c, but considering this branch's focus, that tradeoff makes sense.

Actually, unlike most of the stuff I'm doing here in the name of simplicity, this is actually something that I think would make sense for master if you wanted to do it. It would definitely reduce test time for dependent code and simplify PyPI deployment. The only downside I can see is that we haven't made a habit of manual recompilation yet, but that's all.

from lupa.

How is this different from current master, i.e. specifically this change?

a67720d

from lupa.

Ah, apparently I branched from an out-of-date master. There are some
cosmetic differences because of that - some of the deleted lines are
different - but it's basically the same change in any meaningful sense. I
do feel a little silly for having preached about something the master
branch has already adopted, though!

On Mon, Jul 1, 2013 at 12:54 AM, scoder [email protected] wrote:

How is this different from current master, i.e. specifically this change?

a67720dhttps://github.com/scoder/lupa/commit/a67720daa33929c852fdc139a29219348dbad326

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/14#issuecomment-20267635
.

from lupa.

Turns out I wasn't working on an out-of-date master after all. When I tried to sync my local master with upstream via a git pull, it said I was up to date. So I checked my remotes. And I checked the code. And I figured out where the confusion was.

Your commit detects if generated sources are available, and uses them if they are, falling back to Cython. My code assumes generated sources are available, uses them, and fails with an error if it's not available. So your code still has Cython fallback stuff in setup.py, and my setup.py does not have a single mention of Cython outside the classifiers metadata ('Programming Language :: Cython').

So there is a difference after all, and I misunderstood the changes at play in your commit.

from lupa.

Oh, and Fetchy works nicely now.

https://travis-ci.org/campadrenalin/lupa/builds/8624881

It's up to you how much of this you want to integrate into master. I know master is all about flexibility, so probably just adding Fetch as an option, and maybe removing Cythonization from setup.py.

from lupa.