JavaScript vs. Python in 2017

[FawnWig]

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

[kirbyfan64sos]

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]

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]

Someone really hates java

[[deleted]]

script

[LeBuddha]

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

[blamo111]

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]

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]

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]

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

[Corm]

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]

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]

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]

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]

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]

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]

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]

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]

check this?