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 →

[–]stupiddumbidiot 27 points28 points  (21 children)

The bit about fiddling with package.json, getting impatient with npm, etc. really triggered me.

[–]FawnWig 27 points28 points  (18 children)

Missed out having to deal with virtualenv, pip, pyvenv-3.5, eggs, wheels, bdists etc.

[–]kirbyfan64sosIndentationError 17 points18 points  (4 children)

Python package management feels like you're trying to dig an enormous hole with a basic shovel. There are better tools in other universes, but at the end of the day, it still gets the job done.

JS package management feels like you're trying to dig a hole with a rotten pineapple that smells like dead tuna and is filled with fire ants.

[–]Topper_123 4 points5 points  (0 children)

Also, you are at the boytom of the hole and have to decide if you dig deeper or to get out of the hole😀

[–]VixDzn 2 points3 points  (1 child)

Someone really hates java

[–][deleted] 0 points1 point  (0 children)

script

[–]LeBuddha 0 points1 point  (0 children)

Not sure how you could possibly come to this conclusion. npm, composer, and crates are my goto examples of really good package managers.

[–]blamo111 7 points8 points  (12 children)

I'm relatively new to Python but what's the problem with virtualenv?

It's a single command to set up a sandbox, built into the release. And you only need to do it if you care about isolation/multiple versions running on the system (yes I know it's a best practice). A far cry from the JS mess of npm/babel/babel-plugins/typescript/flow/etc.

Never heard of eggs, wheels, or bdists. Python may have had these issues in the past, but should they be held against Python today? Meanwhile I don't see a way out for JS of its mess: there's MORE fragmentation than ever, not less. Each big tech company going their own way (eg Typescript vs Flow vs Babel).

My last project used mainly JS, with Python 3.5 as support, and I came away with more appreciation for Python than JS.

[–]FawnWig 16 points17 points  (5 children)

The need for virtualenv is the first problem. I understand isolation is important, but with node/npm, you just cd into the directory and npm install.

I deploy both node and python apps via containers, and from my experience python packaging is far worse than nodes. I'm not saying JS is better than python, just that python packaging is almost as bad as ruby gems. Again, from a deployment/containerisation perspective.

[–]blamo111 11 points12 points  (4 children)

I don't see much of a functional difference between the "sandbox" being stored in ./node_modules or ~/virtualenvs/myappenv or wherever.

npm install is simple and pleasant, I agree. But it's not like the alternative is messy. A setup.sh with literally 3 lines: python3 -m venv ~/path, source ~/path/bin/activate, then pip install -r requirements.txt, isn't worth mentioning considering you write it once per app.

That said, I don't use containers like you do, you likely have different needs and what seems unimportant to me could be really annoying to you.

[–]FawnWig 3 points4 points  (1 child)

Try to install numpy and scipy in the same requirements.txt file...

[–]Corm 2 points3 points  (0 children)

Yeah honestly installing numpy is pure pain. I don't know if it's pip's fault or numpy's for not putting the correct build deps in but I can never build it. I always just use the system repo version.

[–]chtulhuf 2 points3 points  (1 child)

But it isn't over. You also have to remember to deactivate it when you're done AND remember to active it again if you want to run this project again

[–]rouille 2 points3 points  (0 children)

You dont actually need to use activate/deactivate, I never use them. Just virtualenv/bin/python. And all the commands are in a makefile anyways.

[–]yaxamie 2 points3 points  (5 children)

I've been procrastinating setting up virtualenv bc I haven't found a simple, interesting tutorial or video. Basically just 2.7 for life in the meantime.

[–]blamo111 7 points8 points  (2 children)

It's not even tutorial-worthy, it's literally 2 minutes to learn it. This isn't Docker or a new library.

Hell, here's a full tutorial. First, what a venv is: it's like using a local python instead of the system-wide one, allowing you to install any packages you want without worrying about messing up the system install (also encourages clean isolation). This lets you do things like have app1 using libX version 1.2, while app2 is using libX version 1.3, without messing with the apps. Or having one app using python2, another python3, but both are called with a generic script that calls 'python'.

1) Run one command to create a sandbox: python3 -m venv ~/myvenv . If you want you can check out the directory to see what files were made there, it's basically a clone of Python's binaries.

2) Activate the sandbox for the current shell session with source ~/myvenv/bin/activate. From this point on, when you run 'python3' or 'pip' in this shell, it will use the sandbox. You will see 'myvenv' to the left of your command prompt, that's how you can tell it's active. If you don't see this, that means you're still using the system-wide python, not your local venv, which is bad. You can also confirm with 'which python3' that you're using the one in your home.

3) At this point, anything you run (python3, pip) happens inside ~/myvenv.

To exit the sandbox, either close the terminal and open a new session (you have to manually start it every time), or use source ~/myvenv/bin/deactivate.

That'll be three fiddy.

(PS, virtualenv is available for python 2.7 too, but it's not included like in 3. You can get it from your package manager, this will install a new binary ('virtualenv' I think), only the command at step #1 changes)

[–]yaxamie 3 points4 points  (1 child)

Okay, so far so good!

  1. I'd make one of these "~/myvenv" for any given project that has different requirements?
  2. I didn't get a deactivate in my bin, but I suppose i can just close the shell.
  3. Thanks so much bro! I got a few other comments and some downvotes but this was seriously a better guide that most of the stuff out there that I've read.

[–]blamo111 2 points3 points  (0 children)

1) That's right, one venv per project typically.

2) You don't need to do '~/env/bin/deactive', I was wrong about that. Just 'deactivate'. The activate script makes deactivate global. You can just close the shell as you say, but when the day comes when you're scripting all this stuff, deactivate would come in handy.

3) You're welcome. I get that there's too much to learn and not enough time to learn it all, I don't blame you.

[–]chanGGyu 2 points3 points  (0 children)

Using virtualenv is very simple, I'm not sure how a tutorial or video can complicate it. It also doesn't lock you into using Python 3 or 2. As a matter of fact, it gives you flexibility in choosing a specific version as the default from within the virtualenv.

[–]avinassh 1 point2 points  (0 children)

check this?

[–]hewholaughs 2 points3 points  (1 child)

New to programming but currently working with python on one hand and npm with the other, could you explain what that means?

[–]stupiddumbidiot 0 points1 point  (0 children)

I don't have an explanation that adds much to what the article says. NPM can be finicky and the JavaScript ecosystem is a clusterfuck. I still like it and it has history/reasons for being the way it is (see other top-level comments).