Pour cette 13ème édition de la journée mondiale de sensibilisation à l'accessibilité #a11y, ARN, @hackstub et le groupe a11y-libre, propose à toutes les personnes qui pratiquent la ligne de commande, un hackaton « asynchrone » sur le thème « ligne de commande et cécité » !
Vous avez jusqu'au 31 mai, pour envoyer vos contributions. Il y a de nombreux lots à gagner.
Notre #hackaton pour rendre les shells accessibles est en cours jusqu'au 31 mai, nous publierons ici quelques contributions chaque jour.
Xogium propose des alias #bash qui désactivent les barres de progressions sur les commandes #docker et #pipenv (#python) car ces 2 commandes détournent des caractères brailles pour l'affichage de la barre...
Voilà qui améliore effectivement l'accessibilité de ces 2 commandes. Il y en a probablement d'autres dans le même genre.
Agreed. I was introduced to poetry a few years ago. After a not-very-long period of using it, I dropped pipenv from everything, and haven't looked back.
poetry has its faults - in particular, when things go wrong, it's almost impossible to get useful diagnostics out of it - but it's an overall improvement.
After Yet Another goddamn time when there was no goddamn way to tell that I was in the wrong goddamn fucking pyenv and broke a bunch of shit by doing a pip upgrade to a package, this sums up my feelings entirely. #python#pythonsucks
An easy way to prevent this in future is to use #poetry (or #pipenv) to install and "lock" your #dependencies (rather than using #pip directly), and check the resulting lockfile into your RCS like any other source file.
If you screw up, poetry install --sync will fix it, including downgrading or removing packages to get back to that known-good state. And if you screw up your lock file, restore it from an earlier point.
@gotofritz As both a former #pipenv user and relatively long time #poetry user my knowledge on what the stock pip experience looks like these days may be a bit rusty, but if you are not pairing with say, pip-tools, then the thing that you'd be missing is lockfiles and their support for transitive dependencies (i.e. track the exact version of your 1st order deps, 2nd order deps, etc.) It's a trade-off between better reproducibility vs ease of getting started with, I guess
@gotofritz 100% with you. Not sure if I managed to verbalize it the way it was intended with regards to dependency tracking. Last time I checked (my view might be outdated here) #pip freeze only tracked first order depdencies (meaning, deps your project explictly depends on) as opposed to what #poetry or #pipenv are able to accomplish with their lockfiles, effectively tracking your entire dependency tree (though you can still do that using pip-tool.)
I'm so fed up with #python at this point. A big percentage of the day to day errors seem so utterly fixable by just having types (yes, I know about mypy and the typing module) and proper package dependency management. We are employing pyright, pylint and mypy just to keep stupid mistakes at bay.
After the upcoming experiment, I'm hoping for some good #haskell and #elmlang time. And possibly exploring #rust (though my motivation for this isn't too high).
IDEA: A #pip / #pipenv wrapper that reports back to you what it is going to install before it installs & reports the security rating/states/download counts, so you can decide if you really want to install it.
This is why we used Docker or another container tech like LXD or FreeBSD jails. There is no need to break the whole thing because a newer version of Python or PHP is installed on your Unix or Linux server.
Learning #python as a JS dev the setup process was confusing, #pipenv does a lot for you in setting up virtualenv but with sane defaults and simpler commands.