Allow to run gulp from any folder. #314

Closed
wants to merge 2 commits into from

4 participants

@khepin

Allow passing an option to the command line --gulp-home or setting an environment variable
GULP_HOME to specify where the local gulp is located.

Sebastien Armand - sa250111 Allow to run gulp from any folder.
Allow passing an option to the command line `--gulp-home` or setting an environment variable
`GULP_HOME` to specify where the _local_ gulp is located.
5790e27
@contra
gulp member
@khepin

Careful, this is actually quite broken now. Committed faster than I should have.

Sebastien Armand - sa250111 Find gulp in GULP_HOME
 * Fix issues locating the right package
 * Get the version from the local package when `LiftOff` doesn't find it
b755b85
@khepin

Should be all green now.

@tkellen
gulp member

Will weigh in on this in a few hours. This is directly related to js-cli/js-liftoff#5

@tkellen tkellen referenced this pull request in js-cli/js-liftoff Feb 28, 2014
Closed

--cwd / --configfile option #5

@tkellen
gulp member

This can be closed, it was addressed in 1c85885 (by moving to liftoff 0.9).

@contra contra closed this Mar 2, 2014
@khepin

Hey, I'm not sure how this solves the issue, but I'll admit I didn't send much explanation with my pull request.

For us, this is the case of a build system where we don't want to re-download our build dependencies (Gulp and plugins in this case) on each re-build. Within the build system, we don't know exactly where Gulp will be except "outside the current directory" and would like to run gulp in our current directory.

I understand that IF there is a local gulp module, this one should be used, but right now there is no other choice than to have the local one.

And it seems the fix you are referring to is not actually fixing things in that way. More in the opposite direction where I am in a directory with all my gulp things installed, but the project is somewhere else and I run my commands from this directory with all the gulp stuff.

I'm not sure I understand why you require a local version of a globally installed module.

@tkellen
gulp member

RE: Global vs local, read this:
http://weblog.bocoup.com/building-command-line-tools-in-node-with-liftoff/

What you get with the current version of Gulp (via Liftoff) is the ability to work with this kind of file structure:

your shared gulpfile

/users/me/deploy/gulpfile.js (a gulpfile to share with lots of projects)
/users/me/deploy/package.json (the dependencies for the gulpfile are listed here)
/users/me/deploy/node_modules (the dependencies for the gulpfile are installed here)

projects to use shared gulpfile

/var/www/project1
/var/www/project2

run gulp from a shared directory, acting as though it is located in a different directory

gulp --gulpfile /users/me/deploy/gulpfile.js --cwd /var/www/project1
gulp --gulpfile /users/me/deploy/gulpfile.js --cwd /var/www/project2

At the present moment, Gulp does not support using an environment variable to search for the gulpfile location (Liftoff has some functionality for this but it hasn't been implemented in Gulp yet). You can mimic this yourself with an alias, though.

One final note: if you run gulp with --gulpfile and no --cwd, it will assume it should run in the directory the gulpfile is located in. You need to specify both if you want to run in this "disconnected" fashion.

@khepin

Well LiftOff seems to be saying "if I don't find the module I'm looking for here, I look up one folder", but by doing so, it also breaks node's default mechanisms that will look for modules in NODE_PATH I don't see why this shouldn't work.

I "think" I understand you always want to load the local version when available, but it doesn't sound like a good idea to break node's standard module loading mechanisms by not trying to load the module from the path if not found locally.

In regards to this, I realize that the solution I proposed here earlier doesn't seem appropriate, I'm open to discuss more on how this could be achieved, but for now the LiftOff update isn't solving the issue I had when submitting this PR.

@tkellen
gulp member

Well LiftOff seems to be saying "if I don't find the module I'm looking for here, I look up one folder", but by doing so, it also breaks node's default mechanisms that will look for modules in NODE_PATH I don't see why this shouldn't work.

Global modules cannot require other global modules unless they are defined as a dependency. If you wanted to use Gulp in this fashion you'd have to make your own branch that defines every plugin you want to use as a dependency. Liftoff doesn't break anything.

@khepin

Hi, I put an example of what I'm thinking about and what I have tried regarding to this at https://github.com/khepin/gulp_example

I explained everything in the readme. This would allow both running the local gulp as is the case right now, but falling back to the global one if no local one (this could be also through an option to allow / refuse this fallback), and then leveraging standard node module loading mechanisms to load non-local modules. Let me know what you think.

@tkellen
gulp member

@khepin I see what you mean. This is an implementation detail for @Contra to decide, it has nothing to do with Liftoff.

@tkellen
gulp member

PS: thanks for your patience, that repo explains what you're thinking perfectly!

@contra
gulp member

I'm pretty confused by this and don't really understand exactly what you need here. Can you tell me very simply what args you want to be able to pass to the CLI and what the expected behavior would be vs. the current behavior?

@khepin

What I want:

I want to be able to run gulp from my project's folder, but with gulp installed somewhere else.

Why I want that:

Build tools (hudson / jenkins in that case) will execute my build scripts from the project folder, but I don't want them to re-download the build tools (gulp & plugins) on each build because if I do, whenever npm is down, or slow (often case in my part of the world), my builds fail for no valid reason.

How I suggest to make it work:

If a local version of gulp is not found, load the global gulp instead. The gulpfile.js can still load the modules that it depends on as long as they are in the NODE_PATH (global modules are OK too).

This would not require any command line flag if the fallback is automatic (as I did it).

@contra
gulp member

So the NODE_PATH behavior is already happening but you want it to fall back to global gulp code when local isn't found. I'll leave this open and work on it when I get a chance

@resistdesign

Anything on this? Seems like it shouldn't be closed. Am I missing something???

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment