1 July 2020
Additionally, if you move this: https://codereview.qt-project.org/c/pyside/pyside-setup/+/288259 to the 5.15 branch, I can add the missing ".pyproject" file, so we can merge it too.
by the way I tried to build pyside by myself to look at the changes in the doc but it always fails on this error :
No such file or directory: '/home/jimmy/dev/bla/pyside /.venv3_install/py3.7-qt5.15.0-64bit-release/bin/rcc': '/home/jimmy/dev/bla/pyside/.venv3_install/py3.7-qt5.15.0-64bit-release/bin/rcc'https://pastebin.com/1RnvUY53
This is a general question, but do you see some value in having a tutorial on stylesheets? At the moment I pushed a simple one to add some colors here: https://doc-snapshots.qt.io/qtforpython-5.15/tutorials/basictutorial/widgetstyling.html
damn no online doc with python3.7 setup.py install --qmake 5.15.0/gcc_64/bin/qmake --parallel=12 --no-examples --doc-build-online
only shiboken doc is generated:
(.venv) jimmy@cacahuete:~/dev/bla/pyside$ ls -aR .venv3* | grep html
html
.venv3_build/py3.7-qt5.15.0-64bit-release/shiboken2/doc/html:
considerations.html
gettingstarted.html
index.html
py-modindex.html
search.html
shibokengenerator.html
shibokenmodule.html
typesystem_arguments.html
typesystem_codeinjection.html
typesystem_conversionrule.html
typesystem_converters.html
typesystem_documentation.html
typesystem.html
typesystem_manipulating_objects.html
typesystem_modify_function.html
typesystem_ownership.html
typesystem_sequenceprotocol.html
typesystem_solving_compilation.html
typesystem_specifying_types.html
typesystem_templates.html
typesystem_variables.html
.venv3_build/py3.7-qt5.15.0-64bit-release/shiboken2/doc/html/.doctrees:
.venv3_build/py3.7-qt5.15.0-64bit-release/shiboken2/doc/html/.doctrees/examples:
.venv3_build/py3.7-qt5.15.0-64bit-release/shiboken2/doc/html/examples:
index.html
samplebinding.html
.venv3_build/py3.7-qt5.15.0-64bit-release/shiboken2/doc/html/_images:
.venv3_build/py3.7-qt5.15.0-64bit-release/shiboken2/doc/html/_sources:
.venv3_build/py3.7-qt5.15.0-64bit-release/shiboken2/doc/html/_sources/examples:
.venv3_build/py3.7-qt5.15.0-64bit-release/shiboken2/doc/html/_static:
Jimpff I'm happy to contribute but it's just so a mess to just add a line in the doc and see the result before pushing. Can't it really be much simplier ?
If someone comes up with a better approach, I will adopt it gladly, the main problem is that the documentation process has many steps
Ссылка
click to show
click to show
if you have any idea how to improve the process, you can share it here: https://bugreports.qt.io/browse/PYSIDE-1106
Ссылка
click to show
click to show
no offense but I give up. I read https://doc.qt.io/qtforpython/gettingstarted.html#building-the-documentation , I bothered you many times and I still can't build this fucking doc (some new error that I won't share). So if push some new other changes, I'll push having no idea of what it could looks like.
I have no idea how to solve the doc toolchain but as you write it I see how complex it is.
Let me take a step back about all this thing:
- Pyside is mainly used( I think) by people from the python community.
- We (python community) usually contribute to project by forking a repo, make change, push et open a PR. Thats all. Sometimes we don't clone the repo locally simply editing doc online
- One day you say "pyside is cool", I'm happy to do a small contribution, but you don't now what's in front of you:
create account, accept conditions, sshkeys, discover gerrit, discover gira, read 3 or 4 pages of manuel, to configure locally, trying to push, install the precommit thing, re trying to push. But you pushed some ugly thing because you didn't test it. Then you say : "If I change the doc I'm gonna build it before next push". So you read 3 or 4 others doc pages, make some google search, ask nice people for help. But no it won't work. You spent hours just to add 2 lines in the docs. You feel bad.
- me eye on it : maybe all those things are usual and basics in C++ world but really it's very disturbing for "usual" python user.
- pyside is supported by a Company and would need to build a big community but with all those pains it'll be hard.
- I would add that python users without real C++ background can quite only contribute in docs. So I'm pretty sure that if building docs means always "all those not so easy building steps" they won't help.
- Is it not possible to split the "standard doc" outside the "apidoc modules" and run pyton setup.p make_doc or something like that ?
Jimno offense but I give up. I read https://doc.qt.io/qtforpython/gettingstarted.html#building-the-documentation , I bothered you many times and I still can't build this fucking doc (some new error that I won't share). So if push some new other changes, I'll push having no idea of what it could looks
Jim gerrit is not only used by the Qt company, I think you realize that. it's actually one of the most used tools for code contribution in big enterprises. I also think that Qt should follow other hub style of projects like gitlab or github. But historically this already happened, and it was a fiasco (Qt was the first major software to join a hub like platform, gitorious.org - nothing worked as planned).
Ссылка
click to show
click to show
I have nothing against gerrit. it's just "one other step" around other things. you inspired my curiosity how I'm maybe too github "focused". I quickly looked at https://hugovk.github.io/top-pypi-packages/ and look at 40 first packages. only 4 are outside github. I should have bought it before microosoft did :-)
But anyway my point was nothing more than my own opinion (and surely not the truth) on things that could prevent the community to be more involved in pyside.
maybe one of the points is that usually in python projects the process are fast and straightforward, like I clone something/fork do some changes, run the tests, and they run in a couple of minutes, and I can I don't know generate some other things, etc, and you can submit some patch verifying everything.
The problem in this case, and in any project that provide bindings to C or C++ libraries, is that you need to deal with the whole overhead from it.
Personally, as a PySide dev, I need to have several Qt versions compiled, and installed from the installer on my system,
I need to have many Python environments, and different versions, and try little features in many different situations.
It was hard, and time wasting at the beginning, because I was not used to it, but now it's simpler.
The problem here is that I have no idea on how to make the building process simpler than now, and that's why the curve is so steep for people which is not used to C++ development environments to collaborate.
I really would love to have something like "python gen_bindings.py" or "python build_docs" but still, I don't see how to speed up the process of querying the Qt installation, get information from the headers, modify and generate C++ wrappers, and compile that for Python to use it.
Maybe the option I pointed out, to only build 'Core' helps, but still you need to take care of having 'libclang', properly setup.
For the docs, it's again the same story, we need to parse the whole Qt framework to get the API documentation, and on top modify some snippets to provide python code.
On that front, maybe one can provide a way to build the docs without Qt API and in that case it will be only a python-sphinx run, but we don't have the resources to do it.
Yes, The Qt Company is a company, but at the moment the devs have 2 keyboards, one for the hands and other for the feet, because there are a lot of things to do and check towards Qt6. Yes, this is not the users problem, but it's just an explan
JimI have nothing against gerrit. it's just "one other step" around other things. you inspired my curiosity how I'm maybe too github "focused". I quickly looked at https://hugovk.github.io/top-pypi-packages/ and look at 40 first packages. only 4 are outside github. I should have bought it before microo
also note that a *lot* - for instance, gnome and kde projects that combined have around 1000 subprojects - can't use github as github is *not* free software.
and I think you are right @cmaureir - for free software to survive it needs some love from the community too.
@cmaureir Sounds like a complex test matrix. I'd expect to have to run the whole test suite „in the cloud“ (= on an integration server running Jenkins, or via TravisCI or similar) and have a small subset running locally. Then, when a push is received on gerrit, the test matrix kicks off and reports back to the issue.
@cmaureir Also, from what you describe, there are many moving parts for generating the docs. How many of those change over time? Can some be cached after first run, so subsequent runs are faster?
Cristián 🥑but some people prefer to run it locally and check before pushing
Sure, that might catch „stupid“ errors, so is a good idea per se. But I wouldn't want to run against different Python and Qt versions
André JaenischI don't want to run the whole test matrix locally
no, I meant that's the CI currently doing. Of course you locally can run even 1 test associated to the issue you are solving
André JaenischPython 2 reached EOL half a year ago
sure, I wanted to deprecate python 2 even a bit before, but we have a couple of customers still on python 2. And I wanted to deprecate 3.5 for Qt 5.14, but it was still a default python for ubuntu back in the day
André JaenischIn case you're not bound by contracts, let it break
yeah, that's the problem, we are :(
in any case, if at some point @RyunoKi Jim @tomazcanabrava you feel like having an idea to improve pyside, even if you don't want or have no time to implement, please feel free to create "Suggestions" in the JIRA system. We usually evaluate them to prioritize items for the future releases. https://bugreports.qt.io/projects/PYSIDE