[WIP] Port switch-to-configuration script to Python#48378
[WIP] Port switch-to-configuration script to Python#48378bgamari wants to merge 5 commits intoNixOS:masterfrom
Conversation
|
CCing @shlevy @Ericson2314 |
FRidh
left a comment
There was a problem hiding this comment.
Move the main code flow into main() and add
if __name__ == "__main__":
main()import statements should all be at the top. Please also add docstrings.
There was a problem hiding this comment.
Would you mind to type annotations, then changing this file becomes easier for type checking with mypy.
I can also add them if you want.
There was a problem hiding this comment.
I was very tempted to add type annotations when I started but wasn't quite sure whether we would want to retain Python 2 support so (mostly) refrained. I would be happy to add them.
There was a problem hiding this comment.
No, we definitely don't want more legacy python2 code.
There was a problem hiding this comment.
consider a function error which calls print with file=stderr
https://stackoverflow.com/questions/5574702/how-to-print-to-stderr-in-python
There was a problem hiding this comment.
use argparse for building the parser. Call it from main().
There was a problem hiding this comment.
Are we ready to accept a >= Python 3.6 as a requirement for NixOS?
There was a problem hiding this comment.
Yes. python36 is the default python3, and soon it will be python37.
There was a problem hiding this comment.
I think what's below this for loop should be in a separate function
There was a problem hiding this comment.
too much nested. Split up in functions.
There was a problem hiding this comment.
Can you add those lines in a one main function instead of mixing functions and code?
|
@Mic92 I think we can add a tiny builder in |
|
There is also pystemd: https://github.com/facebookincubator/pystemd that wraps around libsystemd, |
|
@FRidh I also have some other scripts flying around that can profit from mypy builders: https://github.com/NixOS/nixpkgs/blob/master/pkgs/misc/vim-plugins/update.py https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/analysis/radare2/update.py |
|
I also started rewriting |
|
Pystemd would indeed be very nice for this usecase. @flokli and I have been experimenting with it and it seemed to work really well. I'll have a look at Cython's cross-compilation story. Because I'm not sure either. |
5dcbc76 to
02ce1c6
Compare
|
What about using Jeepney for DBus? It is a pure Python library. |
I considered it but decided against it for now for concerns of correctness and verbosity. I'd be happy to go this direction if others think it best, however. |
|
The current head typechecks with mypy. |
There was a problem hiding this comment.
Functions should also always have a return type also if it its None. Otherwise the type check is skipped if a function does not have any typed arguments.
The build process relies on the glib-marshal utility.
Strangely, they were previously marked as nativeBuildInputs.
13699b1 to
bcc9a6b
Compare
|
@Mic92, this now includes a port of |
|
FWIW, see #48611 regarding |
|
Alright, I will put this aside then. Thanks to everyone who reviewed! |
|
The only Python script in NixOS is |
|
So that one script effectively increases closure sizes by 55 MiB. |
|
@FRidh I just bisected to that very commit. Tough :/ |
|
@edolstra - OOC, is the primary concern closure size? Any thoughts on a more acceptable number (e.g. is a 5MB increase okay)? |
|
@edolstra,j while I'm not attached to Python in particular, I really don't see the sense in using Perl over Python. If anything it seems to me that the residual Perl should be moved to Python, not the other way around. My reasons are three-fold:
A compiled language (Rust or C++) also would be fine here. Really, just anything but Perl. |
|
@andrew-d No, the main concern is not doing gratuitous rewrites. The motivation (cross-compilation) is a weak one because NixOS does not support cross-compilation. Also, I find Python a horrible language to maintain (worse than Perl, even). Rewriting NixOps in Python was the worst decision I ever made. Never again. |
A Rust binary would not be bigger than the 50+ MiB that Python adds to the closure size. All the current Perl scripts (switch-to-configuration.pl, setup-etc.pl, install-grub.pl, nixos-generate-config.pl, update-users-groups.pl, command-not-found.pl) could be replaced by a single Rust binary that shouldn't be bigger than a megabyte or two. |
I'm not sure what you mean by this; Both @Ericson2314 and I have put quite a bit of work into fixing cross-compilation in both Nixpkgs and NixOS. However, at this point I cross-compile NixOS routinely and use it to support a client project. |
|
I give others credit for NixOS in particular :). But yeah as I understand it the only obstical remaining is Perl. I don't love either but Python > Perl is also by far the more common opinion as others have said, and that should be taken into account. I don't think Rust buys us much either. I'm a huge believer in static types, but if everything but the dbus part is shelling out, it's still fundamentally stringly typed. Hardening non-weakest links is a rather pointless exercise. Still, if Rust is the best way for this to move forward, so be it. I haven't looked that much in the nixpkgs some of things, but in principle it should work very well. |
|
Does that actually work at the moment? The shebang paths in switch-to-configuration and other scripts in 64-bit closures won't work on 32-bit systems either. To be honest I don't think it's a use case that needs to be a hard requirement. |
|
Rust would be soon usable w.r.t to cross compiling: #50866 |
|
We can also rewrite those scripts in Bash, bash has a small closure size ;) |
|
They were in bash before, but where rewritten in perl because they were too slow according to the git history. |
|
Concerning
I would just like to repeat my previous point:
I would hope that this disqualifies the language from any use in something as central as the |
This is unique experience. Can you write-up a separate post on "why"? Or is it more personal, so nothing to share? |
If I had to guess, breaking changes in the standard library between major/minor releases. |
|
Besides increasing minimal system closure size, switching to python would increase number of packets required to cross-compile a system closure: Python + some libs + deps would need to be cross-compilable. I nice idea I think is to rewrite
|
That raises questions how the decision on test-driver perl->python rewrite had been passed and why @edolstra did not vetoed it (I agree that as embed language python is terrible + having tab-language within Nix string literals with non-trivial indent stripping and escape sequences is awful) |
Because not many contributors know perl anymore. |
|
Also note perl is probably worse when it comes to cross-compilation than python. |
Yes, we depend on https://arsv.github.io/perl-cross/ which is not very reliable. The project is not very popular and they might stop supporting it at any moment. That's +1 for C++ |
Motivation for this change
Note that this has yet to be tested. Rather I am just posting this as a placeholder.
This is a port of the
switch-to-configurationscript from Perl to Python. The motivation for this change is to ease cross-compilation, which is documented to be quite difficult in the case of Perl (see #36675).One tricky issue that this raises is the lack of sensible
dbusbindings for Python. Each of the options has its share of issues:dbus-pythonis largely unmaintained and binds thelibdbusimplementation, use of which is somewhat actively discouragedpydbususesgobject-introspection, which sadly appears to be very unfriendly to cross-compilationQtDBususes Qt, which is rather heavy-weight for this purpose.Ideally I would like a small binding for
sdbusbut, that not being available, I have simply useddbus-pythonhere.Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)