-
Notifications
You must be signed in to change notification settings - Fork 5
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
Consider env var for the closure library #3
Comments
I have a lame alias in my bashrc: alias cl="ln -s ~/Projects/libs/google-closure-library" And on each project i do Nevertheless, an env var is more elegant and should be implemented |
Of course people could just read from Anyway, for dev mode, people would need a way to serve up the closure lib files, so maybe to really get rid of cloning into a local folder, some kind of server task would need to host the files from the glolbally localted closure lib?! |
Network latency for 100+ required files can be a show stopper. But it might work for getting started... can be worth exploring |
Uhu, I remember plovr having issues with that as well(but I think that was rather related to the java server being used). We could additionally go for an option, so that the lib files could be served from an already existing server. So, how do you do during dev? |
I create a symlink for closure-library inside the project and add 'closure-library' to |
Ok...but then you also serve the lib files from the connect task already(/closure-library/...), no? When using |
There is no (internet) network involved when developing. Closure library is on my hard-disk and available to the project witha a symlink. Connect, the static server, is happy to serve files using the symlink so no issue there. When i was talking about latency i meant the case where we access closure remotely. I see the problem with the env var now... ye a middleware would be required for this case... |
Ah ok, I see : ) Ok, then I'll explore such a middleware a bit... |
He, actually no additional middleware needed - we can just add another call to In the
(instead I think this is even more clean than an env var. What do you think? |
If i understand correctly, we just update the Then by just working with the global |
Yea, it seems so. That makes up for potential naming clashes - if someone would rename the |
Instead having to clone the closure lib over and over again, it would be nice if users could just set an env var pointing to their local copy.
I dont remember really, but I think there were issues with depswriter.py depending on the cwd, so using deps.js in the browser might pose a problem.
Will have a try with this..maybe you have a solution already?
The text was updated successfully, but these errors were encountered: