On 16/04/18 22:22, Andreas Färber wrote:
Hi Simon,
Please respect my Reply-to if you want to have your response read.
Am 16.04.2018 um 03:40 schrieb Simon Lees:
On 16/04/18 07:30, Andreas Färber wrote:
Hello Thomas,
Am 15.04.2018 um 20:16 schrieb Thomas Zimmermann:
On 2018 M04 15, Sun 18:40:08 CEST Andreas Färber wrote:
I've submitted esptool 2.3.1 for inclusion in Tumbleweed:
https://build.opensuse.org/request/show/596756
esptool is a set of tools to work with Espressif ESP8266 and ESP32 microcontrollers.
Hi, it seems we have two devel projects for esptool, the other one is here: https://build.opensuse.org/package/show/CrossToolchain:xtensa/esptool
We should have a look at both of them and decide in which project should be used as devel project.
There is nothing really to decide here... I've already tried to hint you in 2016 that putting random packages into CrossToolchain:xtensa is not a helpful idea - it's not an official devel project for anything. GCC toolchains belong into devel:gcc, Python packages into devel:languages:python and other microcontroller tools into electronics or hardware. Either you want to contribute to Tumbleweed or you want to do your own thing in a hidden corner - that's _your_ decision, not mine.
The python part is not strictly true here, there are plenty of python packages not in devel:languages:python. Many python bindings for other libraries for example live in the devel project of that library, once you get to tools and applications they are spread out all over obs. devel:languages:python is a great spot for python libraries but many other things can have better homes elsewhere.
We're not talking about a random package that happens to have Python bindings along. It's a Python based tool, the tarball is from PyPi, and I've jumped through hoops to follow our Wiki-documented Python packaging guidelines plus Tomas' personal review nits. There is no rule that says, if there's executable Python scripts move the package elsewhere - on the contrary, it's documented how to deal with executables in detail on the Singlespec Wiki page.
For a different packaging project, python-angr, I've encountered several such non-dlp packages that are making things very painful, especially if they don't even get submitted to Factory. They don't follow the same Python conventions (e.g., z3) and get reviewed by different people.
There are equally as many python applications I know of in other places that are also using PyPi, there is certainly some in X11:common. Its a bit like putting emacs in a c/c++ repo because it was written in C. We did discuss this and there was some consensus that d:l:p should generally only have python libraries and python development tools like ide's etc, but know one got around to doing anything about that yet.
Do we need a python2-esptool? I don't know. That's what our macros currently generate and at some point I guess we'll get python4- packages or whatever, it's not hardcoded by me - unlike if you start packaging without using those macros.
We have been suggesting python3 only unless there is a strong usecase for python2 as part of our transition away from python 2 for its up coming end of life.
Speaking of macros, no one appears to monitor and respond to issues filed against python-rpm-macros. Apart from technical limitations I've run into with the new macros, I find it rather ugly to hardcode that our executables in %files should use %python3_only - shouldn't that be, e.g., %executables_python_only (referring to %python_for_executables, where python3 can be overridden via PrjConf once necessary) to avoid having to touch all packages again when there's the next Python version?
SUSE's python team has been undergoing some major changes which is why issues aren't being followed up as quickly, and why some of the documentation is a bit out of date, unfortunately the new people probably won't be up to speed until the second half of the year.
Personally as this package seems to just ship binaries rather then libraries, personally I think it would be better called "esptool" unless there is already an esptool available in another language. I'd also put it in either then electronics or hardware given that by your definition this seems to be "microcontroller tools" rather then a python library.
I would also only ship the python3 version, having a python 2 and python 3 version of the same binary in the repo's doesn't really make sense. If it was a library other python2 applications may still use then maybe. However using singlespec will still make your life easier when we migrate to another python version or interpreter.
Why didn't you do it then? Had someone else done the packaging work, I wouldn't have needed to mess with it and we wouldn't be having these late bikeshed discussions. I'm trying to do it right and had to learn the new Singlespec convention for this package (combining the two Wiki pages would certainly help newbies, and there's also 404 dlp3 links). The documentation does _not_ say it only applies to packages that might be used by Python 2 libraries!
I haven't done the work because esptools is not something I use. I can see your trying to do the right things i'm just trying to help you because clearly there is documentation that could be better. For example the dlp3 stuff was all converted to singlespec and moved back into dlp before the default version of python was swapped.
In practice most Python tools I've encountered instantiate some class that could then AFAIU just as well be used directly from another script, so there's no clear distinction between executable and module AFAIK. Again, I am not a Python developer.
Did you notice that this package depends on two non-Factory packages, python-flake8-import-order and python-flake8-future-import? They're on their way to Factory now thanks to my work (you're welcome!), but so far it was not possible to build esptool without dlp.
Thanks for your help :-)
And as mentioned that is happening all over again with angr, because dependencies are either missing in dlp/Factory or were not converted to Singlespec yet or people build Python sub-packages in ways that have no correlation to how Python (singlespec) packages would actually use them. From my perspective as user, the whole python2 vs. python3 situation is still a big mess, with inconsistent availability of dependencies and several upstreams not yet ready for python3 while we are building certain bindings only for python3 already. On top I've been running into debuginfo(?) packaging issues with Python modules building native libraries, namely capstone (non-Singlespec) and bintrees (Singlespec).
Yep there is still plenty of work to be done, in particular there has been a number of packages in dlp for years that no one has ever bothered submitting to factory, these probably need more of a clean up. Personally I mostly only maintain a few python packages that I use alot in my spare time. I have also encountered the "why is that package only in dlp and not factory" issue several times, then proceeded to fix it. Cheers -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org