xonsh is a Python-powered, cross-platform, Unix-gazing shell language and command prompt
The problem might be that xonsh is a bit more than syntactic sugar
So I'd guess that Astor will turn things into calls into those functions
Not stupid at all
it might be a valid contribution to the community to enable something like we have previously spoken about — I'm pretty positive that Xonsh could become a new standard preinstalled in for example new cloud instances (akin to cloud-init, btw als Python) or in CI systems like Gitlab
we would just need some cheer leading / marketing akin to what NumFocus or Cloud Native Foundation does
and also identify a few concerns / blockers in adoption... which to me the thing that I brought up is the only impediment I see in using it in MLOps related use cases, where we anyways need to work with recent Python installations and environments with non standard dependencies
and I am so sick of working with bash and would like to enable coownership of infra related code as well as interdisciplinary knowledge transfer of software engineering as well as infra knowledge towards data scientists that usually know Python pretty decently but are just stumped by bash...
sry, I'm on the phone and enter sends the message despite being in a further up line..
1 reply
Flask at the time was disqualified as a dependency by one of these non-coding software architect types with the argument that it was in a
0.*-release (so still considered beta, i.e. unstable interfaces) and that it had only around 10 contributors instead of 100+... Funnily enough Flask was the defacto standard for Python microservices at the time, used in Netflix & Co, similar to FastAPI now..
Either way, the argument, not being reasonable for Flask at the time, is something that is reasonable for even smaller projects. Either way, for adoption in corporate contexts and projects that have a multi-year lifespan, it's definitely a line of reasoning that one should have good answers to.
2 replies
input:
#!/usr/bin/env xonsh
if int($(cat /sys/devices/system/cpu/intel_pstate/no_turbo)) == 0:
echo '1' | tee /sys/devices/system/cpu/intel_pstate/no_turbo
print("{PlasmoidIconStart}/home/max/Tools/Turbo Control/Speedometer Off.svg{PlasmoidIconEnd}")
else:
echo '0' | tee /sys/devices/system/cpu/intel_pstate/no_turbo
print("{PlasmoidIconStart}/home/max/Tools/Turbo Control/Speedometer On.svg{PlasmoidIconEnd}")
this is a script that I had lying around that toggles intel turbo boost and interfaces with a KDE plasmoid
after parsing with
xonsh.execer.Execer().parse()and then going back to code with astor.to_source() I get:if int(__xonsh__.subproc_captured_stdout([__xonsh__.expand_path('cat'),
__xonsh__.expand_path('/sys/devices/system/cpu/intel_pstate/no_turbo')])
) == 0:
__xonsh__.subproc_captured_hiddenobject([__xonsh__.expand_path('echo'),
__xonsh__.expand_path('1')], '|', [__xonsh__.expand_path('tee'),
__xonsh__.expand_path('/sys/devices/system/cpu/intel_pstate/no_turbo')]
)
print(
'{PlasmoidIconStart}/home/max/Tools/Turbo Control/Speedometer Off.svg{PlasmoidIconEnd}'
)
else:
__xonsh__.subproc_captured_hiddenobject([__xonsh__.expand_path('echo'),
__xonsh__.expand_path('0')], '|', [__xonsh__.expand_path('tee'),
__xonsh__.expand_path('/sys/devices/system/cpu/intel_pstate/no_turbo')]
)
print(
'{PlasmoidIconStart}/home/max/Tools/Turbo Control/Speedometer On.svg{PlasmoidIconEnd}'
)
Looks like everything comes out as xonsh wrappers, as expected
Like what you kinda want is: transpile, but to only large and well maintained libraries? right?
which seems like a pretty massive undertaking
I think the point of Posix compliant sh scripts being the defacto standard is that they run ony any machine that was provisioned starting from the early nineties and on top of that, by cultural convention, will never be out of maintenance
I was hoping to find a way to contribute to make Xonsh a viable choice for more conservative adoption environments, but I guess the main driver is just how broad the adoption is over time -- the cultural momentum
the latter I mentioned because that's an approach that might be nice to have in the official docs:
The docs are pretty incomplete/partially out of date at the moment as well
The code itself is pretty well documented
but that hasn't been translated into external docs about particular functions well
I've had cases in DevSecOps projects where they chose Go over Python for small applications/scripts simply because you could easily copy the binary around into CI pipelines, etc... these kind of user stories are something that would potentially be really useful in easing general adoption
I was really surprised by how mature Xonsh is and that there are only 3 videos about it on YouTube despite it being seemingly fully functional for around 8 years or so (basef on the first public talk)?
I don't know anything about go. Are the dependencies all bundled in every binary then?
so no non bundled library calls?
Nope, just a user, but if I find something that I want, or a bug to fix, I might contribute that
contributors are users too
idk if there's a hard line
I'm definitely not a maintainer
The one PR I went to open was already fixed on main XD
I hang out in this channel because I was helped by people here when I had/have questions, and so it's nice to be able to help others back
yeah, I really appreciate your input, super nice 🙂 thanks! also thanks to the other commenter (can't retrieve his name, as somehow threads are only accessible when notified in the gitter mobile web UI...)
have a good rest of day @maxwellfire:matrix.org (really cool the quick prototyping especially! thanks..) and anyone discussing this later on, please tag me