-
Notifications
You must be signed in to change notification settings - Fork 0
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
Support specifying module ids instead of file paths to bolt build entry-points and entry-groups #22
Comments
A potential downside to doing this is that we might not be able to support glob patterns for these fields. Not sure if this is a problem or not. |
I really can't remember what we were thinking of doing with the module ids. On Sunday, June 30, 2013, Marli Oshlack [email protected] wrote:
|
Yeah that's the example I was thinking of that would be broken by this. I can't think of any really good solution to this yet. Random ideas:
|
I am leaning towards 3 for now. There are situations where sources can't provide a complete list of modules, so I am not sure if it will ever work with just ids (it may for some small set of cases, but not sure that is worth it). |
Yeah I agree. It looks like 3 is the only real sensible option, although it does seem weird at first. Do you think it's worth making the file paths relative to the src-dir you provide? At the moment, src-dir is a weird option in that the only thing it actually affects is where it publishes flat-modules from. Similarly, should there be a 'test-dir' option, and should test paths be relative to it? Also, is it possible to specify a remote file as an entry-point? Can you only compile stuff if it exists on disk in your src-dir? |
Right now we can compile things from anywhere, but entry-points must be on disk (mainly a limitation of 'inspect' which could be changed). All relative paths can be based in src-dir/test-dir. I think that makes a lot of sense. |
No description provided.
The text was updated successfully, but these errors were encountered: