[Qt-creator] Dealing with python projects

[Cristián Maureira-Fredes]

Hello,

yes I saw your previous email,
let me comment on some of your ideas:

On 4/25/19 4:59 PM, Jason H wrote:
>> Thanks for your feedback Chris, and Jason,
>> hopefully you can help QtCreator to improve on the Python support.
>> I will be more than happy to review your patches.
> 
> I'm not sure if you saw my previous suggestions, but for thoroughness:
> 1. I need something that either uses a conventional entry point or allows me to specify it. (like -e for c compiler)

 From a PySide2 point of view, we try to encourage the __name__ == 
"__main__" instead of a selective entry point, that's why there was no 
change towards that idea, but sure it sounds reasonable.

> 2. Something that uses Python 3. Yes I know Mac only ships with Python 2, but Python 2 is coming to an end in 7 months.

by default right?
I mean, you still are able to change the interpreter to Python3 if 2 get 
automatically selected.

I will be more than happy to drop Python 2 support,
but sadly many people is still not moving to 3, because
they have large code bases or whatever other reason,
so I'm afraid we will keep the support for Python 2 even after 2020.

> 3. Something that allows me to use the shebang #!/... to specify an interpreter. In particular, /usr/bin/env is good at picking one, i.e. /usr/bin/env python3, which sidesteps the hard-coding of the binary to a specific path and picks it up from the user's environment.

I don't know if a connection with the selected interpreter (under the 
Run configuration) is possible, but then again we have the issue that
we will need to have the script with executable permissions to launch it
like `./a.py` instead of `python a.py`.

Maybe the Run configuration could take the information from the shebang 
and update it, just an idea.

> 4. Unfortunately all python projects will be called "main" in the project explorer. Maybe the entry point should be $1.py where $1 is the name of the project and/or directory?

Since that was the first attempt, yes,
but a couple of weeks ago I tuned a bit more so now the names of the
files are configurable: https://codereview.qt-project.org/#/c/255686/
> There is lack of clarity on what the proper python project file format is. I wonder why the existing C++ infrastructure can't be re-used? The differences (as I currently understand them):
> 1. No compiler - this is just a no-op.
> 
> 2. The C convention entrypoint of main() is not present, therefore we need to specify it. (i.e. either use -e main like for clang or PYTHON_ENTRYPOINT=main.py) Python scripts often also have a library/main test:
> if __name__== '__main__':
>      pass  # I am the entry script, parse sys.argv, etc. (great for testing)
> else:
>      pass  # I am invoked as a library providing functions
> 
> Also entry points usually executable and have a shebang, though this is not needed.
> 
> 3. SOURCES should be .py files and merged with DISTFILES for copy into the build dir. HEADERS can be ignored?

It's mainly the fact that the qmake/qbs are not design for Python,
so finding a solution was tricky in the sense we needed to bypass many 
things.
That's why long time ago (when the PythonEditor plugin was added),
the simple .pyqtc format was used as a simple approach to this.

I believe the main motivation for making qmake/qbs Python compatible
will come from the community, because at the moment it's not a
priority for the people behind PySide/Creator.

I see the next steps as only expanding the .pyproject file
to include more entries, since it's a quicker approach.

Hopefully we can get the community more involved,
so we can have a proper Python support in QtC.

> Questions:
> 1. Maybe there can be a pythtondeployqt?

The deployment topic is tricky,
we spend some time assessing the existing solutions
to deploy Python applications, and we found that
a couple were really robust, so we didn't to reinvent the wheel
and give them a try.

At the moment we have a set of official tutorials on how to use them
and we want to see how the community reacts, and which tool is required.
Since most of them require some love, maybe it will be worth to
contribute to those projects than writing our own tool.

Hopefully in following releases we can choose one of this applications,
like PyInstaller and integrate it as the "deploy option"
for Python projects.

> 2. Could we have a mixed-mode project where some C/C++ is built along with the python? Python Extending is a thing (https://docs.python.org/3/extending/index.html) Not sure if Qt provides Python helpers like Qt Android JNI helpers for calling functions and workin with Java Objects?

This is also a good suggestion and we have been also
discussing the possibilities, since many Qt for Python users
are playing a lot with our binding generator tool, Shiboken.

We have an example [1] that shows one possible "mixed use"
of both Qt/C++ and Qt/Python, in simple words it's a Qt/C++
windows with a QTextEdit on where you can write Python code,
and then run it on an embedded interpreter.

Other example [2] is one that generate the Python bindings
for a C++ (Qt-independent) project, and uses them from a Python file.

At the moment we heavily rely on a tuned CMakeLists.txt file and
some configuration scripts, but once we are reaching a simpler approach
it will be totally a priority to make them QtC compatible.

[1] 
https://code.qt.io/cgit/pyside/pyside-setup.git/tree/examples/scriptableapplication
[2] 
https://code.qt.io/cgit/pyside/pyside-setup.git/tree/examples/samplebinding

Thanks for your feedback.
Cheers


-- 
Dr. Cristian Maureira-Fredes
Software Engineer

The Qt Company GmbH
Rudower Chaussee 13
D-12489 Berlin

Geschäftsführer: Mika Pälsi,
Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
--