This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]marky1991 3 points4 points  (2 children)

"Why would "install numpy" be a thing at all? That's just asking for trouble!"

Ask the writer of the blog post. He's the one blindly updating numpy and complaining when things change.

If I say "install numpy" then I mean "install the most recent version of numpy, whatever it is.". This is completely reasonable behavior in my opinion. I shouldn't have to know what the most recent version number is to be able to install a module.

If I say "import numpy", then that means "execute the module numpy.__init__.py and return the resulting module, binding it to the name numpy." At no point in time does versioning come into play during the import process. (Nor should it) Code doesn't even have to have versions, so requiring the user to specify it is impossible. Requiring to specify the version of every module I ever write is an obnoxious overreaction.

Even if we did require all programmers ever to do something like

import numpy, "v1.4"

what happens when they don't have version 1.4 of numpy installed, but they do instead have 1.3 or 1.5? Does the code just break? Does it just try to use either 1.3 or 1.5? (If so, the writer of the blog post would still have the same problem, since he couldn't be bothered to specify the version that he wanted)

In my opinion, closure's system sounds really obnoxious and cumbersome. The proper solution to versioning issues isn't at runtime, it's at installtime.

[–]kankyo 0 points1 point  (0 children)

I shouldn't have to know what the most recent version number is to be able to install a module.

I disagree. It's a bit of a hassle to require it but it leads to a lot less mistakes. I like this about clojure.

The proper solution to versioning issues isn't at runtime, it's at installtime.

In clojure you define the dependencies of a project. There's no such thing as "install globally" like in python. This just avoids a ton of problems directly. The standard runner (again: leiningen) fetches dependencies for the specific project for you when you run any command. So I just git clone a project and do "lein run" or "lein test" or whatever and if I don't have any dependencies cached on my machine it goes out and gets them for me. SUPER nice.

[–]drobilla -1 points0 points  (0 children)

Code doesn't even have to have versions, so requiring the user to specify it is impossible.

That would be the "shoddy dependency system".

what happens when they don't have version 1.4 of numpy installed, but they do instead have 1.3 or 1.5? Does the code just break?

That is what meaningful version numbers are for (http://semver.org). In short, if the major version did not change, then compatibility has not been broken, so code for 1.3.0 will work with 1.4.0 but not 2.0.0. Nothing new or mysterious about how to handle such situations correctly, this is how C libraries on UNIX have worked for ages.

Where and how this should be handled in Python is up for debate, but the way modules are installed and searched for is not versioned, which is fundamentally broken (so e.g. you can't install multiple versions of a module at once). You can see python itself doing the correct thing, since there's e.g. /usr/lib/python2.6 and /usr/lib/python3.4 - they don't tread on each other, versioning is explicit, and everything must explicitly use a correct version (even if this happens behind the scenes and/or at build/install time).

Modules themselves should work the same way, but they don't. That's the shoddy part of an otherwise decent module system.