batavia
batavia copied to clipboard
compile_stdlib.py improvements
The compile_stdlib.py
is a program that converts standard library .py
files into .js
files by compiling them to bytecode (pyc
), and then encoding that in JS.
This is completely a Python program, and most of the these tasks should require little or no JS knowledge.
There are a number of improvements that we would like to make to this tool.
- [x] Accept arguments to specify what libraries to include
- [x] Modify it to produce the
batavia.js
file itself, patching it together, rather than doing it in theMakefile
- [ ] Have arguments for common library collections (e.g.,
--basic-stdlib
for a lighter standard library, once we have more of it implemented) - [ ] Your other cool ideas go here
Another idea: make the path to the Ouroboros directory a configuration flag.
And another: a configuration file storing the build options that can be passed in at runtime. This enables the build options to be version controlled as part of a build/deployment system.
Hey! I am a first timer and want to contribute towards this project. So, could you explain a little bit more about this issue?
Hi @parvmor - Batavia consists of two parts:
- the core language interpreter
- the Python standard library.
Much of the Python standard library doesn't have to be re-written - we can just use the code from CPython itself. This is because much of CPython's standard library is written in Python. The pure Python implementation of the CPython standard library is contained in the Ouroboros project.
However, in order for Batavia to use that code, we need to process the contents of Ouroboros into bytecode format so it can be packaged with Batavia. This is done by the compile_stdlib.py
script.
So - the initial task is to modify compile_stdlib.py
to include more packages from the standard library provided by Ouroboros.
The secondary task is to provide a way to customise compile_stdlib.py
so that an end user can customise which parts of the standard library are included. If you're delivering a web app, size matters, so there's no point delivering parts of the standard library that aren't going to be used. Being able to specify or customise the parts of the standard library that will be included in your Batavia build would be helpful.
Does that clarify the requirements enough for you to get started?
Hi @freakboy3742 , I'd like to contribute on this issue. My question is : would this be helpful to add an argument to compile_stdlib that lists available modules so the end user doesn't have to crawl through the paths to see what's in ouroboros module folder.
2nd question is : In ouroboros module folder there is also folders (like urllib
), we should be able to include libs that are in these subfolders.
#https://github.com/pybee/batavia/pull/313/commits/c9da5bf5b5177c9b86d9462842c49e3c054be07f
This commit doesn't check subfolders and can only include first level modules.
I thought that we could specify a module that's included in a "package", and also a whole package.
@mrPain89 yes - an argument to list the available options sounds like it would be helpful.
As for submodules; yes - submodules should also be included. The code you reference is almost certainly an oversight, based on the fact that the modules that have been explicitly supported so far are all shallow (I think?). If the UI allowed you to specify the top level module, which then automatically included all the submodules, I think that would be sufficient.
Hi @freakboy3742 thanks for explaining that to me. I have added the functionality to include the submodules :) . What else shall I do now?
@freakboy3742 Is this issue still available?
@Divya063 yes - there's still a couple of the features initially flagged that are up for grabs!
Hi! I am a first-time contributor and just wanna find out if there are any more issues that are up for grabs?