jbang
jbang copied to clipboard
jbangdev
allow //DEPS ./deps.txt and even https://pathto/deps.txt
might have some path collisons with jitpack support but now several times seen projects like FXGL or similar that has actually perfect standalone main apps in their sample projects but either wont or wont make sense to duplicate //DEPS in every file it would be useful to just have dependencies externalized.
means you can add //DEPS deps.txt to any file and just maintain deps in one file without having .java code mixed in.
BUT
also allows you to do jbang --deps path/to/deps.txt https://..../PhysicsDemo.java
for easy testing on your own but in addition you as a library/project owner can "jbangify" your project by just providing a deps.txt.
I do think this is a useful feature to have, but .... for that last option I'd rather go with the jbang-config.json file. That way you can "jbangify" your project without the user having to type anything extra :-)
That would require jbang to always locate and parse jbang-config when running... not a fan.
Unless we keep as it is today we don't rebuild unless source has changed or --fresh present.
In any case I think this issue is separate from deps.txt support. One can be implemented without the other.
That would require jbang to always locate and parse jbang-config when running... not a fan.
You mean remotely, right? True, that might be an issue. Unless, like you mention, we cache them and don't try to update them on each run.
Btw, thinking about it some more I think I'd prefer dependencies to be explicit anyway, instead of being looked up in a config file. It's okay that it's possible but perhaps not the "proper" way to do things.
hmmm....should we make it //INC jbang.txt instead and it could include any amount of //JAVA, //DEPS, //JAVAC_OPTIONS etc. ?
then it most definitely won't conflict with other syntaxes but would need an new command line flag (like jbang --inc jbang.txt ...)
and it could include any amount of //JAVA, //DEPS, //JAVAC_OPTIONS
But isn't that basically the same as //SOURCE ? Just with a weird restriction that it can't contain code :-)
But isn't that basically the same as
//SOURCE? Just with a weird restriction that it can't contain code :-)
kinda - but that is the intention as some report a allergic reaction to seeing java code too early :)
Other advantage is you can have it reused/shared without "injecting" code.
Sure, I wasn't suggesting to actually use //SOURCE for this feature :-)
But what I do want to discuss it the way we could implement this and what the actual requisites are.
Because this started as a relatively simple list of deps and has already grown to include things like JAVA and JAVAC_OPTIONS.
Are those useful additions? I think so yes, but I haven't really thought about it very deeply.
And the format? Any text file that should only contain // lines?
Or perhaps just ignoring any lines that do not start with //? That way you could "copy" the settings from an existing .java file.
Or should we use some other format? We already have .json support for example (what we use for aliases). (Not that I think that's actually a good option, but just throwing it out there).
Wait wait wait, didn't we talk about a similar feature a long time ago, an //INCLUDE or //IMPORT feature where you could literally include the contents of another file? Because in that way we could actually make it a completely generic feature: anything that's in that file would be included as-is into the current source file: // lines and code. That way you could re-use short snippets of code without having to turn them into a library.
Hey @quintesse, it's nice to work with you again :)
//IMPORT seems like a better name as it doesn't imply it will be part of the content like //INCLUDE does (that would get duplicated if added more than once)
WDYT of this:
- If the file doesn't contain any
//we take it as a if there were//on all lines - else we take it as a standard script file with
//lines and code
Hi @ia3andy :-)
You are right in your assessment of INCLUDE vs IMPORT, but that's exactly why I wanted to have this discussion, because I actually think it "being part of the content" is an advantage, it could be a very nice feature.
If you have a directory full of useful JBang scripts it might be a very common situation that many of them will not only use a common set of dependencies and compile options but also a set of helper functions. In that case //INCLUDE would be a better fit.
You don't have to include code of course, in that case you'd write a file that only contains // lines.
It has the added advantage that the file format stays exactly the same as for source files so we can reuse the existing code without (m)any changes.
WDYT of this
I'm afraid that this could lead to ambiguities. There are source files that won't have any // lines (JBang doesn't require a source file to have any) and a developer could also write a file with only // lines and no code.
So how can you be sure what is what? You'd have to take a look at all the lines and make sure all of them only start with DEPS, JAVAC_OPTIONS, JAVA etc. But that could cause issues with forward/backward compatibility (currently we just ignore // lines with unknown labels).
There might be ways around that but I'm not sure the additional work is worth it to just be able to remove two slashes from each line. KISS.
Btw, a good point against the use of //INCLUDE would be that the implementation would become more complex. We'd have to create a temporary file containing the source of both (all) files and pass that to the compiler. Which is perhaps something we don't want to do either.
In that case using only the // lines from a file would be much simpler and //IMPORT would be the better name.
In fact let's forget //INCLUDE because I just realized it would mean that we'd probably get all kinds of problems with package and import keywords appearing in the wrong place in the (merged) source files. Bad idea :-)
So my final design suggestion would be to use //IMPORT on files that follow the same rules we use for source files. That way we can simply reuse the current ScriptSource support: when you encounter an //IMPORT line you get a ScriptSource for it and then merge all its deps, options, etc with the parent ScriptSource.
This way you can either just write a file containing only // lines or you can import the // lines from an existing source file, both would work.
Perhaps an easier way would be to adapt the getLines() method to recursively return all // lines from the parent file and all imported files.
NB: It should only return lines that start with //, where right now it returns all lines. But everywhere getLines() is used the first thing the code does is filter out any lines that don't start with // so it should be safe to make that change. Maybe change it to getCommentLines() or something.
Btw @maxandersen , I see that integrations get passed the original source file and have to do their own comment parsing if they want to read any // lines. That wouldn't work very well for this feature (however we decide to implement it). It would be better if we could pass only pre-parsed comment lines instead. Could we do that or is that a breaking change?
@quintesse with respect to integrations then I don't think we should start mutating the source files passed in here - it has to be the actual source.
I can see it would useful to have access to additional data but I would say we should pass that in as additonal data - like we do pass in the dependency list.
with respect to what goes into the file I would
This way you can either just write a file containing only
//lines or you can import the//lines from an existing source file, both would work.
yes - I would say this is fine. We can also add meaning to the extension and only allow .jbang, .java,.kt to somewhat limit/guide usage and allow us to introduce more dedicated formats in the future.
I can see it would useful to have access to additional data but I would say we should pass that in as additonal data - like we do pass in the dependency list.
@maxandersen but that would then mean having to pass all affected options as "additional data". Because with this new feature any // lines can be affected. In fact the integration cannot simply use the // lines from the passed source anymore, it must use the passed information.
We can also add meaning to the extension and only allow .jbang, .java,.kt to somewhat limit/guide usage
I think this again leads to ambiguities. We already allow source files to have no extension. So what if I want to do //IMPORT myscript? (Where myscript is really a java or jsh source file)>
Unless we want to introduce specifically named files for the "simplified" import file, eg: mysettings.jbinc and do //IMPORT mysettings.jbinc.
But do we really want to introduce that just to be able to remove some slashes? It just seems to go against the KISS principle IMO.
//IMPORT myscript
Wouldn't be a problem. No extension is fine.
Btw import isn't a great name. It will be listed near actual import statements :)
Wouldn't be a problem. No extension is fine.
It won't be a problem if we just assume that you could include/import any file with // lines in it (ie anything currently supported by the ScriptSource).
I'd prefer it if we simply start out with that option and keep any other formats for possible future extension if we or users really want a //-less format.
Btw import isn't a great name. It will be listed near actual import statements :)
Indeed. Well there still is //INCLUDE, although I'm slightly worried (but only slightly) that people could take it to mean including any source code that might be in the file as well. I can't come up with any good alternatives though, //ASSUME perhaps.