objectionary
EO compiler does not work without internet access
@dours good point. I think we should implement a local cache of .eo objects, similar to what we have in ~/.m2/repository directory. Maybe it should be ~/.eo directory.
@andreoss can you implement this? I think the only class this should affect is the PullMojo. It will try the local cache first and if the .eo file is not found, it should go to Objectionary. Maybe we can just create a decorator for Objectionary object, which will do this type of caching.
@andreoss also, would be great to listen to the --force option of Maven and if it's provided, enforce from-Internet downloading. I'm not sure whether it's possible though.
@dours good point. I think we should implement a local cache of
.eoobjects, similar to what we have in~/.m2/repositorydirectory. Maybe it should be~/.eodirectory.
Why not make the environment variable EOPATH (for example) in which to store the path to the folder in which to store the runtime .eo files and the compiled eo-runtime-vX.Y.Z.jar? This is probably similar to what you are suggesting.
Then we don't need to download anything every time, and the files along the EOPATH will be managed by the eo.jar part (for example).
It will be able to download the required runtime version and compile it into a jar file. For example:
eo update-runtime
# downloads runtime files to EOPATH
# compile them to jar
And the compiler itself will be able to pull up all the necessary files and runtime. At the very least, we will get rid of the need to build the runtime every time, as well as not download the source code of this runtime.
@andreoss I like the idea of EOPATH, which should be ~/.eo by default. Keeping .jar files there is also a good idea, on top of keeping there .eo files. Maybe like this:
.eo/
binaries/
org.eolang/
eo-runtime-0.21.2.jar
sources/
org/
eolang/
txt/
sprintf.eo
@yegor256/z everybody who has role DEV is banned at #490; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)
@yegor256/z everybody who has role DEV is banned at #490; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)
@yegor256/z everybody who has role DEV is banned at #490; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)
@yegor256/z everybody who has role DEV is banned at #490; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)
@yegor256/z everybody who has role DEV is banned at #490; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)
@yegor256/z everybody who has role DEV is banned at #490; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)
@yegor256/z everybody who has role DEV is banned at #490; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)
@yegor256/z everybody who has role DEV is banned at #490; I won't be able to assign anyone automatically; consider assigning someone manually (as in §19), or invite more people (as in §51), or remove the job from the scope (as in §14)
@dours indeed, I'm closing this. We keep .eo files in ~/.eo directory. They won't be downloaded again, if Internet access is lost. Of course, for the first time you will have to have Internet access to download them.