Every time I use Python I miss NPM and package.json.
pipenv is like npm for python and Pipfile works similar to package.json. There's even a Pipfile.lock
pipenv is more like yarn (same version locking concept)
My Python Development Environment, 2018 Edition
101–110 of 224 posts
Re: My Python Development Environment, 2018 Edition
#102I just have latest Python installed and the nice support on Visual Studio. https://www.visualstudio.com/vs/python/
This, me too. I never understood the need for virtualenv and similar. Do people really encounter trouble with conflicting packages that often? I try to write scripts so they run on different versions of python anyway, unless there is a very specific reason why that is not possible; and even then you can run python versions in parallel on a Debian/Ubuntu box, with different pip installs for each of them. As for produc…
Do you just use one environment for every project?
That gets messy. What if you want to setup a new machine? Or a new employee's machine? Etc..
It isn't only about conflicting packages.
Re: My Python Development Environment, 2018 Edition
#103I don't understand this at all. It's 2018. My dev. env. for is some text editor that knows how to "jump to definition" and "find all usages" (this is sometimes referred to as "IDE"), and a bunch of Dockerfiles to build and run the tests.
yup, same here.
Re: My Python Development Environment, 2018 Edition
#104Re: My Python Development Environment, 2018 Edition
#105Earlier quoted context omitted.
How does it compare to PyCharm?
It's on par, as long as you don't do too many refactors on nasty codebases. Now, PyCharm chokes on those nasty refactors too, guessing the right stuff only 70% the stuff in a way that sometimes feels purely random, but at least its find and refactor preview UIs save the day sort of... One thing that annoys me on VSC is that some operations (jump to defnition etc.) have delays on larger projects, because it does not c…
Type hints have made PyCharm an even more amazing IDE. Start using them if you're on a version of Python that supports it! :)
Re: My Python Development Environment, 2018 Edition
#106Earlier quoted context omitted.
Anaconda does most of the stuff mentioned, and also makes it much easier to install packages based on C/C++ libraries (which most deep learning things are). So you're better off staying with anaconda. It's widely used in commercial data science projects so the idea that noone "takes it seriously" as someone else suggests is a bit silly. I assume they're thinking about a different context to data science projects. Tha…
> ... and also makes it much easier to install packages based on C/C++ libraries I hear this often, though I cannot remember ever running into a pip package where this was an issue. Out of curiosity, could someone point me to a pip package and its conda equivalent where this is the case?
Try pip installing scipy or Numpy and you'll see the value of conda.
Re: My Python Development Environment, 2018 Edition
#107Seems like you could get all this done with conda. Just a thought.
I'm all for trying new things, but yeah I did have a similar thought. Conda is a good general-purpose tool that seems to check all these boxes and I've never had any serious issues with it.
Re: My Python Development Environment, 2018 Edition
#108as someone who has to manage projects for multiple clients, I find docker + docker-compose to be the best solution. The overhead of docker is totally worth it because the container separation makes life so much easier.
all I need to work on a client project is basically:
cd /path/to/project
docker-compose build (just once)
docker-compose up
Re: My Python Development Environment, 2018 Edition
#109Would it be easier to use individual docker containers, each their own python environment and then have your source directory mapped to a docker directory?
I guess, if you are cool with sharing the images when you need to share the environment. I think I just never liked the "bulk" that comes with Docker, though it has gotten better.
I think Docker is cool in general but for other stuff than this specific use-case.
Re: My Python Development Environment, 2018 Edition
#110Since switching to nixos, my Python development environment couldn't be more satisfying. I use a default.nix file and a requirements.txt file and then with a single command I'm into a shell and virtual environment with all dependencies and packages installed, that I can easily transfer between machines. That is unless I want to use PyQt5.
What is the issue with PyQt5?
PyQT5 is actually packaged, and I was just being lazy in my comment.
It's actually pyqtchart and qscintilla that are the problems. They're not packaged for nix and won't install in a virtualenv with pip. Something to do with hardcoded paths for dependencies I think.
I'm going to have a go at writing a nix files that build them from source, with the help of a NixOS expert, so we'll see how that goes.