Open touilleMan opened 4 years ago
I think it depends on your target user in mind. For me, I use godot-python because I use python every day for work, so I'm very comfortable using the command line, creating virtual environments, etc.
If we think most people use godot-python are using it for similar reasons, I think we wouldn't need a GUI or too much automation, though some is appreciated. Do you get any sort of reporting / numbers on how many people use the project? Obviously there are a decent amount of questions regarding getting it working here on Github but that could be a small fraction of users who aren't familiar with Python.
Definitely love the approach of only committing a requirements and config file though.
For me, I use godot-python because I use python every day for work, so I'm very comfortable using the command line, creating virtual environments, etc. If we think most people use godot-python are using it for similar reasons, I think we wouldn't need a GUI or too much automation, though some is appreciated.
I totally agree, Python ecosystem already work in a certain way so we should try to stay as close as possible to it.
Side note here: I'm doing Android development on my daily job and seeing Android studio which is basically IDE+emulator+cross compilation toolchain+debugger+packager+dependency management+bitcoin miner (judging by how much ram/cpu this monster eats :trollface: ) I'm definitely convinced we don't want to take the path of a fully integrated development experience ;-)
Do you get any sort of reporting / numbers on how many people use the project?
Nop, I have absolutely no idea who's using the project
Definitely love the approach of only committing a requirements and config file though.
;-)
Side note here: I'm doing Android development on my daily job and seeing Android studio which is basically IDE+emulator+cross compilation toolchain+debugger+packager+dependency management+bitcoin miner (judging by how much ram/cpu this monster eats :trollface: ) I'm definitely convinced we don't want to take the path of a fully integrated development experience ;-)
Definitely. In the same vein as above, I believe if you're wanting to use Python in Godot, you probably have a preferred editor already so no need to re-invent the wheel. Just make the Godot specific stuff as painless as possible and the Python ecosystem can handle the rest. That's why I love the recent stub file support here.
For me the primary purpose of using godot-python is to get access to the python package ecosystem. Of course it would be nice with a dev environment, but I think there are more prioritized improvements that can be made first =). Not sure I have them in mind, but basically making it work smoother and with less bugs when trying to use the python ecosystem in Godot.
I'm familiar with Python but in a less professional way; comfortable with doing things on the command line, not as comfortable with creating virtual environments (I've dealt with it occasionally). I'm toying with doing a voxel game on an aperiodic lattice (3D Penrose tiling). This means I have to do a lot of computation, at least initially, to generate the lattice. The project started out using Java, and I got tired of how many lines it took to write something that I knew could be one line in Python. What I'm trying to get at is, I'm using python for overall ease of use. GDScript is neither as pleasant to write as Python, nor is it as fast for something complex like generating an aperiodic grid. And thanks to this project, writing Python is more convenient than writing GDNative.
Anyway, my basic preference for development environment vs. release environment would be that a beginner could get by without noticing the distinction, IE, the current pip method should work unchanged, the dev path and the release path should be the same by default, etc.
Something I'm still not sure about is how to make the difference between the development installation and the release installation of python dependencies.
For instance you could install cython, black and numpy when developing on your project, but when doing the release you would only want numpy (given cython is only needed at compile time and black is a tool to keep the code clean).
It feels like we would need two virtualenv (one dev, on release) preconfigured, so instead of doing:
we would do:
Here the
--target=...
install the packages in the given folder, so we keep theaddons/pythonscript
folder unchanged (it site-packages folder still contains nothing and doing.\addons\pythonscript\windows-64\python.exe -m cython
will complain the module is not installed)From there we could have two separate DEV_PYTHON_PATH and PROD_PYTHON_PATH options in the godot python settings.
Some issues on this though:
python -m ensurepip
prior to any pip install. It would be better to automatically do this on install (or maybe ship directly pip, but given it's not something CPython is doing I guess it's not a good idea to do it ourselves)addons/pythonscript/window-64/python.exe -m pip install --target=<>
is a complex command, it would be much better to have a script wrapping this (typically using thegodot --script=my_script.gd
command, though is this really simpler if user has to typegodot --path my_project --script res://addons/pythonscripts/pip_for_dev install black
?)On top of that, it could be good to add support for requirements.txt (having DEV_REQUIREMENTS_PATH/RELEASE_REQUIREMENTS_PATH in godot python settings). A full setup.py support seems to much of a hassle from my point of view given how messy this format is (cf. pyproject.toml, setup.py, setup.cfg, setuptools, distutils, poetry and other buzzwords ^^).
I'm currently working on install manager for pythonscript: you would install this installer from the assetlib (it's only a couple of .gd files and is designed not to changes too often), then it would be responsible for downloading&installing the last version of pythonscript compatible with your OS and Godot version. On top of that the installer could also be responsible for doing the
python -m ensurepip
andpython -m pip install --target=python_deps_release -r $RELEASE_REQUIREMENTS_PATH && python -m pip install --target=python_dev_release -r $DEV_REQUIREMENTS_PATH
This seems like a good way to bootstrap your project on a new computer (hence the user wouldn't have to save pythonscript and the python dependencies as part of it game project, but only the requirements.txt and potentially a small config file specifying which version of pythonscript should be used)
However this ask the question on how to add/remove dependencies to the requirements.txt and update the virtualenvs accordingly... Should we leave this to the command line or can we provide a GUI within Godot to allow user to do this in a user friendly way ?