Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experimental branch that fetches and builds luajit #14

Closed
MaddieM4 opened this issue Jun 27, 2013 · 7 comments
Closed

Experimental branch that fetches and builds luajit #14

MaddieM4 opened this issue Jun 27, 2013 · 7 comments
Labels

Comments

@MaddieM4
Copy link
Contributor

The biggest struggle with actually using Lupa in any kind of production environment, in my experience, has been platform-specific breakage due to the variable nature of the install process. We do probably always want flexibility in the mainline branch, but for the sake of stability, predictability and testing validity, I'm gonna make a less-flexible branch that handles its own acquisition of luajit.

@scoder
Copy link
Owner

scoder commented Jun 27, 2013

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

@MaddieM4
Copy link
Contributor Author

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" notifications@github.com 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
.

@MaddieM4
Copy link
Contributor Author

MaddieM4 commented Jul 1, 2013

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.

@scoder
Copy link
Owner

scoder commented Jul 1, 2013

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

a67720d

@MaddieM4
Copy link
Contributor Author

MaddieM4 commented Jul 1, 2013

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 notifications@github.com 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
.

@MaddieM4
Copy link
Contributor Author

MaddieM4 commented Jul 1, 2013

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.

@MaddieM4
Copy link
Contributor Author

MaddieM4 commented Jul 1, 2013

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.

@MaddieM4 MaddieM4 closed this as completed Jul 1, 2013
@scoder scoder added the fixed label Feb 12, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants