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. 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. 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? https://github.com/openSUSE/python-rpm-macros
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.
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
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! 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. 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. libraries, namely capstone (non-Singlespec) and bintrees (Singlespec). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org