My Python Development Environment, 2018 Edition • Hacker News Board

Re: My Python Development Environment, 2018 Edition

#221

Post by mixmastamyk » Sun, Feb 25, 2018, 11:03 PM UTC

moogie wrote: post #220

mixmastamyk wrote: post #218

Earlier quoted context omitted.

Never happened in twenty years. Manually installed packages are already segregated and can be uninstalled ya know. Might be a problem if you have no admin skills.

Way to miss the point!...all of them! Nobody said anything about manually installed packages being unsegregated or immutable, so let's not put up any more straw men. It's just a stupid way to work. I think you may be the one without admin skills if you think working on your system Python is anything except reckless. No one cares that you have 20 years of doing it like that, it's a poor argument and shows up a really…

Your appeal to absolutes reeks of immaturity, lack of experience, and cargo-cult reasoning.

On the contrary, if it rarely to never happens compared to the effort involved, it's not "reckless" at all, but a tradeoff. The site package folders are a simple path of files/folders, not hard to reason about. Nothing gets "hosed" without your participation. No need to live in mortal fear. In other words the cure is as bad as the disease.

The truth is that venvs are a hack with a lot fewer use cases now that user packages at the low-end and containers at the mid/high-end are now ubiquitous.

Honestly newbies would be a lot better off just avoiding venvs entirely. I make an exception for pipenv when appropriate since it hides the complexity as well as possible.

Re: My Python Development Environment, 2018 Edition

#222

Post by cmcginty » Mon, Feb 26, 2018, 12:10 AM UTC

joshmaker wrote: post #208

wirrbel wrote: post #156

Earlier quoted context omitted.

Don't forget that usually you'll start to sort your requirements into dev requirements and production requirements which makes these packaging scripts much more complicated. https://github.com/jazzband/pip-tools would be what I used before pipenv came to be.

Two features I miss from pip-tools: 1. `pip-sync`, An easy way to ensure my local environment actually matches my defined requirements. I guess the pipenv version of this would be `pipenv uninstall --all && pipenv install` which isn't quite as elegant, but perhaps good enough. 2. The ability to create more than two requirement sets. For my projects it's often handy to three sets of requirements: • Normal production r…

  pip-compile --upgrade
  pip-compile --upgrade-package

are also necessary features to quickly track your dependencies (and transitive deps).

pipenv uses pip-tools, but they haven't exposed these features as far as I can tell.

Re: My Python Development Environment, 2018 Edition

#223

Post by AlexCoventry » Mon, Feb 26, 2018, 2:50 AM UTC

cat199 wrote: post #210

AlexCoventry wrote: post #143

Earlier quoted context omitted.

Emacs has pretty nice integrations with inferior docker processes. I'm getting them via spacemacs, so I'm not sure what specific package provides it, but I assume it's elpy.

what kinds of interactions? (like: what operations, etc) using elpy here with a native install and can use e.g. tramp for remote editing/python sessions in most cases (even across machines), but determining docker mount points to edit in-machine not so much.. I suppose one can simply map a local code directory into a runtime environment, but this also makes e.g. interacting with an in-container interpreter a bit both…

C-c C-p will start an inferior python shell in the container, for instance.

Re: My Python Development Environment, 2018 Edition

#224

Post by kalefranz » Mon, Feb 26, 2018, 2:17 PM UTC

james_the_cat wrote: post #62

natch wrote: post #27

I’m using Anaconda because it was recommended in a step by step tutorial for playing with deep learning. What would be involved in removing it from my system and moving instead to this set of tools? Not necessarily looking for s step by step answer, just for general suggestions. My guess is: find out which python the deep learning tools are using, remove Anaconda, and reinstall the python version needed, using the to…

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…

> like packages not being backwards compatible with old versions of conda

When new capabilities are added to conda, like the ability to support noarch python packages, you're going to need to be working with an up-to-date version of conda to use those packages. Just `conda update conda`.

> conda going crazy and reinstalling itself

Conda will pretty aggressively auto-update itself. Going crazy and reinstalling is a new one though. File an issue with details at https://github.com/conda/conda

> the way the conda-forge repo has far more packages than the official conda repo

Conda-forge is community driven and more "upstream" than the Anaconda, Inc.-provided 'defaults' repositories. Think of conda-forge like Fedora, and 'defaults' like CentOS/RHEL.