Menü
Avatar von nikeee
  • nikeee

216 Beiträge seit 07.03.2014

Re: 1 Mio. Pakete

CoolAllo schrieb am 09.10.2019 23:40:

Das ist ganz normales Defaultverhalten.

Dann erkläre mir, warum diese Issue existiert und nicht geschlossen ist:
https://github.com/pypa/pip/issues/1668

Paketmanager sind Luxus. Luxus den ich als Nutzer erwarte, aber nichts was mich daran hindern sollte es auch anders zu können.

"Es auch anders tun zu können" != "per Default allem auf den Fuß treten." Warum dann kein "--global", was man explizit setzen muss?

Ich rede nicht über deine Pakete, sondern ich rede darüber wie es technisch funktioniert.

Genau das habe ich beschrieben. Es werden beide installiert und man sagt selbst, welches man verwendet. Wenn du nicht weißt, wie man ein in der package.json definiertes Paket verwendet, kann ich dir da nicht weiter helfen.

Ich verstehe das Problem nicht.

Vernünftig designt = wir brauchen keine Shellskripte, die die aktive Shell mit Aliasen und Funktionen patchen, damit unser Packagemanagement _angenehm_ funktioniert (Betonung auf _angenehm_).

./configure make make install

Dann weißt du sicherlich, dass das im optimalfall das ist, was pasieren sollte. Meistens fehlen noch 2-3 Buildabhängigkeiten. Oder es wird nicht make sondern $ANDERES_BUILDSYSTEM verwendet.
Siehe:
- https://pypy.readthedocs.io/en/latest/build.html
- https://docs.scipy.org/doc/numpy-1.15.0/user/building.html

Und stell dir jetzt ein 12-Jähres Kind an seinem Raspi vor, wie es arm-none-eabi-gcc installieren muss, weil "pip install" für ein Paket nicht funktioniert hat.

So, und genau das tut dein activate auch für Pythonpakete.

Tu nicht so, als wüsste ich nicht, was das tut. Das ist mir klar. Der Bedarf daran ist aber total sinnlos. Es geht auch komplett ohne Änderung von irgendwelchen Envvars. Und dann brauche ich auch keine Shellspezifischen Dinge. _Jeder_ andere Paketmanager macht das anders.

Herrgot, dieses Virtualenv-Zeug ist sogar so daneben, dass selbst die Leute von Pip das Projekt Pipenv den Untertitel geben "Python Development Workflow for Humans.".
Und sie schreiben sogar, dass sie es so machen wie alle anderen:
"Pipenv is a tool that aims to bring the best of all packaging worlds (bundler, composer, npm, cargo, yarn, etc.) to the Python world."
(was impliziert, dass es vorher nicht "best of all packaging worlds" in Python gab)

Sie haben sogar ehemalige pip-Maintainer, die jetzt froh sind, dass Dependency Management jetzt besser geht:
https://github.com/pypa/pipenv#-user-testimonials

Leider ist es nur ein Wrapper un Virtualenv. Die Notwendigkeit, es so zu machen, liegt wohl eher in Python als in den Package-Managern (eben wegen des Python-Paths).

Das machst du bei npm übrigens ganz genauso, wenn du keine Lust hast mit "npm install -g" etwas nach /usr/local zu installieren (siehe oben, ich halte das meistens für nicht so gut).

Ja, das halte ich auch für einen Design-Fail. Manche User haben den npm-Prefix nämlich nicht gesetzt und installieren dann viel zu oft als Root.

Ich habe hier zum Beispiel:

Ich habe ein besseres, über die .npmrc:

prefix=/home/username/.npm-bin

(entsprechender $PATH-Export vorausgesetzt, wenn man Tools darin verwenden will)

Und ja, man möchte "npm install -g" verwenden und nicht alles in eigenen Ordnern liegen haben, gerade wenn du node Programme installierst.

Normalerweise braucht man nichts (außer npm selbst) global installiert haben. Vielleicht noch ein paar Spiel-Tools, die nicht in Projekten selbst verwendet werden. Es sei denn natürlich, du willst zwingend andere Versionen verwenden, als sie der Build-server oder deine Kollegen haben.

Ich verstehe dein Problem nicht. Du kannst es mit drei Zeilen in deiner Bashrc und einem Ordner lösen.

Wenn ich 3 Zeilen in meiner Bashrc habe, installiert er es ja wieder alles in die selbe Location.
Ich kann natürlich auch diese [0] 80 Zeilen in meiner Bashrc haben. Aber dann kann ich natürlich auch gleich Virtualenv nehmen. Oder Virtualenvwrapper?

[0]: https://github.com/pypa/virtualenv/blob/master/virtualenv_embedded/activate.sh

was du vorhin noch als npm Vorteil gepriesen hast

Es hat ja auch Vorteile, u. A. Reproduzierbarkeit. In anderen Managern (NuGet, npm, cargo) ist ein Projekt == eine Umgebung.

Die gleiche Aussage. Wozu willst du die sonst haben, wenn du sie nicht brauchst?

Die Betonung sollte nicht auf "ich will das", sondern "ich brauche das _jetzt_ und will vorher nicht noch das Halteproblem lösen".

Du lädst das Source-Paket aus einem neuerem Release (z.B. sid bei Debian, wenn du wirklich bleeding edge haben willst), erzeugst einen neuen Release-Eintrag und baust das Paket mit dpkg-buildpackage. Danach installierst du es einfach mit dpkg -i. Wahlweise kann man auch recht leicht selber ein Repo zusammenbauen.

Habe gerade einen Haufen informatikfremde Data-Scientists vor Augen, denen du erklärst, wie sie ihre Debian/Windows/Centos/sonstwas Pakete bauen müssen, damit sie alle auf der selben Version arbeiten können, bevor sie mit ihrer Arbeit fortfahren.

Wenn ich ein Paket nutzen möchte, dann lese ich erst einmal, ob es mein Problem löst. Das sollte natürlich dokumentiert sein.

Und genau das ist es doch. Wenn ich Probleme mit isNaN habe, dann werde ich genau auf diese Lösung kommen. Gibt keinen Grund, den kompletten Standard dort noch mal zu rezitieren.

Keine Ahnung? Vielleicht nutzt er es einfach, um das Verhalten, das du vorhin so toll definiert haben wolltest, zu definieren.
Vielleicht sind die Tests auch dazu gut, um fremdes Monkeypatching zu catchen?
Oder es liegt einfach daran, dass er die Tests vor der Implementierung geschrieben hat.

Alles Antipatterns.

Diese arrogante Aussage wage ich anzuzweifeln. Das ist aber nicht Thema. TDD finde ich aus anderen Gründen aber oft nicht angemessen.

Wenn du x !== x schreiben willst machst du Test-Driven-Development?

Nein. Aber vielleicht sind diese Tests dabei rausgekommen, als er das Verhalten vom normalen isNaN untersucht hat? Wer weiß.

allerdings trotzdem deutlich mehr als am Ende im Code landet.

Habe gehört, dass soll in anderen Sprachen gelegenlich auch so sein.

Rennen!

Dann wirst du wohl nie eine Seite schreiben, die JS hat. WASM ist schon weit, aber ohne JS wirst du ne Weile nicht auskommen.
Also hast du selbst nicht den Hauch einer Lösung und meckerst, dass andere Leute eine gefunden haben?

Du testest damit aber nicht deinen Code, sondern die Engine, das sind halt zwei paar Stiefel. Wenn die Engine sich undefiniert verhält, kann dein Test auch Unsinn ergeben.

Wo ist der Unterschied, wenn ich asserten will, dass sich die Funktion überall gleich verhält?

Verstehst du warum ich über JS lästere? ;-).

Nein. Weil "hihi, guck mal, was für eine große Tabelle das ist! :D:D"? Ziemlich infantil.

Ja. Genau das ist das Problem. Und Leute schaffen es ja auch in ihrer CI-Pipeline das Paket tatsächlich jeden Tag neu herunterzuladen.

Wo ist das ein Problem? Hast du perfektes Package-Caching bei dir? Ich oft, aber bei weitem nicht immer.

Wenn meine Engine so buggy ist, habe ich größere Probleme als die Unittests meines Pakets.

Das stimmt.

Bewerten
- +
Anzeige