Ergebnis 1 bis 20 von 385

Thema: IM IN YR LOOP\n VISIBLE FOO\n IM OUTTA YR LOOP - Der Programmierer-Spamthread #2

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Ich verzichte freiwillig auf 10% Gehalt, wenn das heißt, dass ich NIE WIEDER mit einem User reden muss.
    Alle User müssen brennen. Dasselbe gilt für IT. My life is strictly a developer only space now.

  2. #2
    Der Ton hier ist genau der gleiche wie im IRC-Channel unserer Sysadmins.

    Zitat Zitat von WeTa Beitrag anzeigen
    Docker ist doch ein •••••••••, aber nur auf Windows.
    Docker ist überall ein •••••••••. "sudo apt-get install •••••••••" <- installiert Docker. Es gibt 2 Arten von Entwicklern: Entwickler noch nichts gescheites mit Docker gemacht haben und Entwickler die Docker scheiße finden.

    Stattdessen kann ich normale LXC-Container mit Orchestrationsoftware (um schnell mal einen Dev-Container zu bauen) empfehlen; hat sich einigermaßen bewährt.

  3. #3
    wer ist eigentlich auf die enorm kluge idee gekommen, dass C-c in GUI Kopieren ist und auf CLI Prozess killen

  4. #4
    Ich verlasse mich nie mehr auf irgendwas, was ich im Internet lese.
    Internet: Python ist gut! Tatsächlich leider: Python ist nicht gut.
    Internet: Perl ist nicht gut! Tatsächlich aber: Perl ist gut.

  5. #5
    Und jetzt soll ich mich auf das verlassen, was ich von dir im Internet lese?

  6. #6
    Zitat Zitat von DFYX Beitrag anzeigen
    Und jetzt soll ich mich auf das verlassen, was ich von dir im Internet lese?

    sollten wir in this.next() besprechen

  7. #7
    Zitat Zitat von WeTa Beitrag anzeigen
    Ich verlasse mich nie mehr auf irgendwas, was ich im Internet lese.
    Internet: Python ist gut! Tatsächlich leider: Python ist nicht gut.
    Internet: Perl ist nicht gut! Tatsächlich aber: Perl ist gut.
    Ne stimmt nicht. Python ist gut.

  8. #8
    boah weiß nicht
    Zitat Zitat
    virtualenv is a very popular tool that creates isolated Python environments for Python libraries. If you're not familiar with this tool, I highly recommend learning it, as it is a very useful tool, and I'll be making comparisons to it for the rest of this answer.

    It works by installing a bunch of files in a directory (eg: env/), and then modifying the PATH environment variable to prefix it with a custom bin directory (eg: env/bin/). An exact copy of the python or python3 binary is placed in this directory, but Python is programmed to look for libraries relative to its path first, in the environment directory. It's not part of Python's standard library, but is officially blessed by the PyPA (Python Packaging Authority). Once activated, you can install packages in the virtual environment using pip.

    pyenv is used to isolate Python versions. For example, you may want to test your code against Python 2.7, 3.6, 3.7 and 3.8, so you'll need a way to switch between them. Once activated, it prefixes the PATH environment variable with ~/.pyenv/shims, where there are special files matching the Python commands (python, pip). These are not copies of the Python-shipped commands; they are special scripts that decide on the fly which version of Python to run based on the PYENV_VERSION environment variable, or the .python-version file, or the ~/.pyenv/version file. pyenv also makes the process of downloading and installing multiple Python versions easier, using the command pyenv install.

    pyenv-virtualenv is a plugin for pyenv by the same author as pyenv, to allow you to use pyenv and virtualenv at the same time conveniently. However, if you're using Python 3.3 or later, pyenv-virtualenv will try to run python -m venv if it is available, instead of virtualenv. You can use virtualenv and pyenv together without pyenv-virtualenv, if you don't want the convenience features.

    virtualenvwrapper is a set of extensions to virtualenv (see docs). It gives you commands like mkvirtualenv, lssitepackages, and especially workon for switching between different virtualenv directories. This tool is especially useful if you want multiple virtualenv directories.

    pyenv-virtualenvwrapper is a plugin for pyenv by the same author as pyenv, to conveniently integrate virtualenvwrapper into pyenv.

    pipenv aims to combine Pipfile, pip and virtualenv into one command on the command-line. The virtualenv directory typically gets placed in ~/.local/share/virtualenvs/XXX, with XXX being a hash of the path of the project directory. This is different from virtualenv, where the directory is typically in the current working directory. pipenv is meant to be used when developing Python applications (as opposed to libraries).

    As of writing, pipenv has not seen a release on Pypi since November 2018, and there are no commits on GitHub since November 2019. The documentation website pipenv.org is down (#4137), and users are posting issues asking whether pipenv is dead


    tooling so anstrengend wie bei javascript

  9. #9
    Perl ist wegen den ganzen CPAN-Modulen und der immer noch relativ guten Geschwindigkeit ganz brauchbar aber ein größeres Perl-Projekt bei dem mehr als 3 Personen Code schreiben würde ich heute nicht mehr anreißen (den ganzen Wahnsinn um $_, @_, Skalar/Listenkontext,... und den 1000 Möglichkeiten um genau die gleichen Standardroutinen zu implementieren würde ich mir nicht ohne guten Grund antun). Vielleicht Ist Raku/Perl 6 in der Hinsicht besser; hat zumindest mal vielversprechend ausgesehen.

  10. #10
    Ja, was Großes würde ich damit auch nicht anfangen, aber ich glaube das ist jetzt meine Lieblings-"Kurz was scripten"-Sprache.

  11. #11
    Ich muss aber auch sagen, dass Python keinen Spaß macht. Ja, es ist für gewisse Use-Cases wahnsinnig schnell, aber das Tooling ist echt einfach nur grauenhaft, insbesondere wenn man Python als Abhängigkeit von irgendwas in ein anderes Projekt einbindet und nicht ein reines Python-Projekt macht. Da wäre etwas wie Composer eine Million mal angenehmer zu benutzen als Pythons obskurer Salat aus venv, pip, pro-Projekt-Runtimes und weiteren Dingen, die mich nicht interessieren, wenn ich einfach nur einen in Python geschriebenen PDF-Renderer mit seinen Abhängigkeiten in meiner C#-Anwendung verwenden will.

    Ich habe das Gefühl, dass Python so eine polarisierende Sprache ist. Entweder geht man voll darin auf oder man findet sie furchtbar.

  12. #12
    Zitat Zitat von WeTa Beitrag anzeigen
    Ja, was Großes würde ich damit auch nicht anfangen, aber ich glaube das ist jetzt meine Lieblings-"Kurz was scripten"-Sprache.
    Das ist für mich in der Regel der Punkt, wo ich zu Ruby greife, das ja ursprünglich genau für diesen Anwendungsfall als Perl-Nachfolger entwickelt wurde.

  13. #13
    Ja stimme zu, Tooling ist katastrophal.
    Ich dachte die Aussage bezog sich auf die Sprache an sich, die ist nämlich sehr schön.

    pyenv funktioniert an sich problemlos, aber was die 30 venv Varianten angeht ist es ein wenig die Suche nach dem geringsten Übel. Wer ein Lockfile für dependencies braucht, kommt um pipenv wohl nicht herum, es sei denn man möchte die dependencies selbst resolven. poetry ist vielleicht ein Hoffnungsschimmer, verfügt aber noch nicht über die essentielle pipenv install --deploy Funktion.

  14. #14
    Meine Lösung war, den ganzen Kram inklusive Runtime zu einer monolithischen DLL zu kompilieren. Manchmal kommt man mit sowas durch...

    (Ich mag die Sprache selbst tatsächlich auch nicht, aber das ist persönlicher Geschmack und kein Problem der Sprache an sich.)

  15. #15
    Ich sehne den Tag herbei, an dem WSL einfach mal funktioniert.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •