5 ms·

The main drawback of python for me, compared to NodeJS is the whole sharing projects onto different machines with virtualenv or whatever. package.json and node_

The main drawback of python for me, compared to NodeJS is the whole sharing projects onto different machines with virtualenv or whatever. package.json and node_modules just works by default in so much cleaner a way. You can use npm or yarn or just a zip of the node_modules to share the environment with a colleague or to deploy.

beagle3 7y ago
conda solves that for python at least as well as npm/yarn does. I don't understand while it is not in wider use (except for lack of PR).
- fitech 7y ago
  how does conda solve this? Will conda fallback to pip if the conda repository doesn't contain one of your dependencies?
  - athorax 7y ago
    With your conda environment activated, you can run pip install requirements.txt. You don't have to use any of the conda commands outside of creating the environment.
- athorax 7y ago
  conda / miniconda has definitely solved most of my grievances with deploying python applications
- physicsguy 7y ago
  If you want to add your own project to Conda, you need to use conda forge, because Anaconda itself is a curated distribution. Maintaining a conda forge package has been, for us, a complete nightmare. If you depend on another conda-forge package you can have the issue that the library is configured to suit whoever first wrote the conda-forge package - i.e. by disabling parallelism or providing only shared/static libraries, and have that maintainer be completely unresponsive or unwilling to change it.
  - msarahan 7y ago
    That is a downside of community maintenance, for sure. Conda-forge probably needs official policies and suggested workflows to have multiple varieties of recipes where feasible. There is never a one-size-fits-all solution when a community serves so many different people with so many different use cases. Spack fits the "my way and only my way" mentality better. Conda is more "close enough, and already ready for me to use."
  - scopatz 7y ago
    If you let us know about the package, we can work with you to create a variant.
wolf550e 7y ago
What is wrong with virtualenv, pip and pip freeze?
- _never_k 7y ago
  They work, but there's much more friction and many more gotchas than node. The requirements file for example, doesn't distinguish between direct and ancestor dependencies, it has to be explicitly passed to pip, you need to have created and activated your virtual environment correctly, many python libs have fragile, c based builds. Node and nvm just work.
  - wolf550e 7y ago
    I use separate requirements-to-freeze.txt and requirements.txt, so that I maintain only list of direct dependencies (no transitive dependencies) and only pin versions when I know the code won't work with the latest version, but pip freeze creates a file like package lock with all the dependencies versioned so I can recreate the exact environment again without needing to store a docker image of it or something like that. See https://www.kennethreitz.org/essays/a-better-pip-workflow https://www.kennethreitz.org/essays/a-better-pip-workflow Needing to name the requirements file and needing to activate venv are not pain points I feel. Wrapping native libraries and not invoking a C compiler at package install time means some trade-offs. https://cffi.readthedocs.io/en/latest/cdef.html https://cffi.readthedocs.io/en/latest/cdef.html
buildbot 7y ago
I feel like this is a common argument, but a bit disingenuous. One of the major reasons venvs are more complex and less portable than node_modules is it's fairly rare for node to bind to c/c++, but very very common for python to do so.

beagle3 7y ago

conda solves that for python at least as well as npm/yarn does. I don't understand while it is not in wider use (except for lack of PR).

fitech 7y ago
how does conda solve this? Will conda fallback to pip if the conda repository doesn't contain one of your dependencies?
- athorax 7y ago
  With your conda environment activated, you can run pip install requirements.txt. You don't have to use any of the conda commands outside of creating the environment.
athorax 7y ago
conda / miniconda has definitely solved most of my grievances with deploying python applications
physicsguy 7y ago
If you want to add your own project to Conda, you need to use conda forge, because Anaconda itself is a curated distribution. Maintaining a conda forge package has been, for us, a complete nightmare. If you depend on another conda-forge package you can have the issue that the library is configured to suit whoever first wrote the conda-forge package - i.e. by disabling parallelism or providing only shared/static libraries, and have that maintainer be completely unresponsive or unwilling to change it.
- msarahan 7y ago
  That is a downside of community maintenance, for sure. Conda-forge probably needs official policies and suggested workflows to have multiple varieties of recipes where feasible. There is never a one-size-fits-all solution when a community serves so many different people with so many different use cases. Spack fits the "my way and only my way" mentality better. Conda is more "close enough, and already ready for me to use."
- scopatz 7y ago
  If you let us know about the package, we can work with you to create a variant.

wolf550e 7y ago

What is wrong with virtualenv, pip and pip freeze?

_never_k 7y ago
They work, but there's much more friction and many more gotchas than node. The requirements file for example, doesn't distinguish between direct and ancestor dependencies, it has to be explicitly passed to pip, you need to have created and activated your virtual environment correctly, many python libs have fragile, c based builds. Node and nvm just work.
- wolf550e 7y ago
  I use separate requirements-to-freeze.txt and requirements.txt, so that I maintain only list of direct dependencies (no transitive dependencies) and only pin versions when I know the code won't work with the latest version, but pip freeze creates a file like package lock with all the dependencies versioned so I can recreate the exact environment again without needing to store a docker image of it or something like that. See https://www.kennethreitz.org/essays/a-better-pip-workflow https://www.kennethreitz.org/essays/a-better-pip-workflow Needing to name the requirements file and needing to activate venv are not pain points I feel. Wrapping native libraries and not invoking a C compiler at package install time means some trade-offs. https://cffi.readthedocs.io/en/latest/cdef.html https://cffi.readthedocs.io/en/latest/cdef.html

buildbot 7y ago

I feel like this is a common argument, but a bit disingenuous. One of the major reasons venvs are more complex and less portable than node_modules is it's fairly rare for node to bind to c/c++, but very very common for python to do so.