touilleMan / godot-python

Python support for Godot šŸšŸšŸ
Other
1.88k stars 143 forks source link

Separate development and release python environments #247

Open touilleMan opened 4 years ago

touilleMan commented 4 years ago

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:

$  .\addons\pythonscript\windows-64\python.exe -m pip install cython black numpy

we would do:

$  .\addons\pythonscript\windows-64\python.exe -m pip install --target=python_deps_release numpy
$  .\addons\pythonscript\windows-64\python.exe -m pip install --target=python_deps_dev cython black

Here the --target=... install the packages in the given folder, so we keep the addons/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:

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 and python -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 ?

cridenour commented 3 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.

touilleMan commented 3 years ago

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.

;-)

cridenour commented 3 years ago

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.

thetoblin commented 3 years ago

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.

dranorter commented 3 years ago

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.