16 ms·

My Python Development Environment, 2018 Edition

• meddlepal 9y ago
  I have added PyInstaller (http://www.pyinstaller.org/ http://www.pyinstaller.org/) to my toolchain recently for working with Python app distribution. It gets me pretty close to the Golang single distributable executable ideal... the main issue is needing to build on each target OS, which kind of sucks but I can deal with.
  • MereInterest 9y ago
    I've used pyinstaller on Wine in order to make Windows executables from Linux. Haven't figured out yet how to cross-compile for OSX yet, but that at least reduces it from requiring three major OSes to build to two.
    • book_mentioned 9y ago
      Have you had a chance to evaluate https://pybee.org https://pybee.org ? src: https://news.ycombinator.com/item?id=16419628#16420689 https://news.ycombinator.com/item?id=16419628#16420689
      • RightMillennial 9y ago
        Other than promoting Python and "diversity", what exactly does PyBee/BeeWare do? It sounds like an SDK, but it appears to just point to a bunch of random GitHub projects. It's not very clear to me.
      • XorNot 9y ago
        After some digging I've still no idea if it solves my core problem of needing a Mac to build Mac binaries.
    • meddlepal 9y ago
      We have low interest in Windows support for our software so I haven't even tried yet but WINE is a good idea if it works. For MacOS a TravisCI Mac build should do the trick. It'd be nice if it could all be done in a single run..., but it doesn't seem possible.
  • pritambarhate 9y ago
    Yes, I am also using PyInstaller for an infrastructure automation CLI project I am doing. Works really well to produce the single executable. Also for most of the automation work, you don't really need Go's speed. Python's convenience makes iterating a lot quicker.
• miketery 9y ago
  Is there a command needed in pipenv like the one needed in virtualenv? eg. > source env/bin/activate How does one activate one environment over another? Why is pipsi a separate thing?
  • UtahDave 9y ago
    You just cd into your project's directory and run "pipenv shell" and it activates the virtualenv for you.
  • paddyoloughlin 9y ago
    when you want to run a command 'inside' the pipenv of the current directory, do: > pipenv run {command} This mirrors how npm works. There's also: > pipenv shell to give you a shell in which the environment is setup correctly for you
  • icebraining 9y ago
    pyenv/pipenv are for your development. pipsi is for installing Python tools/applications that you just want to use, like apt/yum.
  • rovr138 9y ago
    Based on install.rst[0] It seems it keeps a ledger somewhere (haven't dug into it). Then to run commands, instead of using `python main.py`, you now use `pipenv run python main.py` and it automates things. It still depends on Virtualenv. As an alternative, Pyenv + Pyenv Virtualenv work by creating the environments in a separate folder. You can then `cd` into a project root folder and there use `pyenv local x` and every time you `cd` into the directory or a subdirectory, it looks up the tree until it finds a `.local` file. This specifies the environment. It can be a Python version or a Virtualenv and it loads it. [0] https://github.com/pypa/pipenv/blob/4f2295a1dbf7fe6fa36ef4ec92b758acf60e1710/docs/install.rst https://github.com/pypa/pipenv/blob/4f2295a1dbf7fe6fa36ef4ec... [1] https://github.com/pypa/pipenv/blob/4f2295a1dbf7fe6fa36ef4ec92b758acf60e1710/docs/install.rst#-installing-packages-for-your-project https://github.com/pypa/pipenv/blob/4f2295a1dbf7fe6fa36ef4ec...
• mlevental 9y ago
  there are way too many python dep/env managers/things pipenv pyenv mkvirtualenv virtualenv pipsi venv pew conda virtualenvwrapper i'm sure i'm forgetting like 5. this is like https://xkcd.com/927/ https://xkcd.com/927/ for the record i use pyenv and virtualenv (although playing with ML i'm using conda)
  • yeukhon 9y ago
    As a Python developer, I just stay with pip and virtualenv, but I share the smh/wtf sentiment here. The data science folks enjoy conda but I don't see that being useful to me anywhere else. I feel like every other year someone will invent a new pip env. pyvenv (see comment section, edited) is now deprecated and venv is recommended (shipped as part of Python 3.6 installation) is another confusion. Lest not forget the confusion of distuilts and setuptools is like argparse vs optparse in the past (which are both horrible). The experience of using pip and pypi (now Warehouse) is much better than that of Ruby and of NodeJS, but these "2-in-1" tools are just ridiculously "creative". As always, pro-tip: consider using the following to ensure environment is loaded properly when you are deploying production /full_path/env/bin/python myapp.py --workers=3 over source /full_path/env/activate && python myapp.py --workers=3 The latter is fine when you are doing local development in your terminals. If you go on #python IRC channel, every year a group of helpers will collectively recommend one of the above and then perhaps a different one the following year, so please do yourself a favor, just stick to pip and virtualenv.
    • Cyph0n 9y ago
      Conda is especially useful if you want to use scientific packages on Windows.
      • SatvikBeri 9y ago
        Yeah, I use pip + virtualenv on most machines (and have for years), but conda is the only one that actually seems to "just work" on Windows.
      • yeukhon 9y ago
• erokar 9y ago
  Every time I use Python I miss NPM and package.json.
  • na85 9y ago
    You miss a package manager layered on top of the one already in your OS, one that's seemingly run by people with no clue what they're doing, is rife with security issues and can break your entire system as we saw today? I have no clue why a sane person would run npm.
    • pbreit 9y ago
      And yet millions do?
      • bussierem 9y ago
        Millions of people believe in chakras, horoscopes, and homeopathy - argument from popularity is a logical fallacy for good reason. Consensus does not equal quality.
      • fatbird 9y ago
        And those same millions have been halted simultaneously in development around the world by the removal of key packages due to namespacing issues. Or, today, we find that running the newest version of npm under sudo can rewrite file system permissions across the entire hierarchy. What was that you were implying about how the choice of millions is probably pretty good?
      • na85 9y ago
        Millions of people write their passwords down on little slips of paper next to their monitor. Are you implying that because something is popular, it's therefore "good"?
  • cpburns2009 9y ago
    In what way is NPM and package.json different from using pip and requirements.txt?
• pjmlp 9y ago
  I just have latest Python installed and the nice support on Visual Studio. https://www.visualstudio.com/vs/python/ https://www.visualstudio.com/vs/python/
  • ju-st 9y ago
    How does it compare to PyCharm?
    • user5994461 9y ago
      Having worked a few years on both, they're both great.
    • deleted 9y ago
      [deleted]
    • nnq 9y ago
      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 create an "index db" of your code behind the scenes like PyCharm does, so it can show you usage and search for stuff practically instantly. Overall VSC is great for developing Python on not-huge and well-behaved projects. For degenerated overgrown messes it's not a good solution :)
      • sorenjan 9y ago
        Visual Studio Code is not the same as Visual Studio, which is what the op was referring to.
      • zie 9y ago
        Just an FYI.. The parent comment was about Visual Studio(https://www.visualstudio.com/vs/python/ https://www.visualstudio.com/vs/python/), and you seem to be commenting about Visual Studio Code(http://code.visualstudio.com http://code.visualstudio.com), which are 2 totally different products. Microsoft has terrible naming practices.
• ben_jones 9y ago
  I haven't had to write python in awhile but are there reasons to use virtualenv etc. instead of a docker container?
  • Karunamon 9y ago
    Less of a pain in the ass for rapid iteration, zero overhead, fewer dependencies = less complexity. Virtualenv is literally a set of shims in your $PATH and some tooling to manage those sets. Pyenv is the same thing, but extends the concept out to your actual Python interpreter and lets you rapidly switch between them.
  • raverbashing 9y ago
    Yes you don't need a whole linux distro for what's simply a set of libraries and a binary file Docker container is just the lazy solution
  • encoderer 9y ago
    I wish you weren't getting downvoted for this. docker-compose is honestly no more complicated of a thing than virtualenv to use. That said, main reason to do it is that python is a language of idioms and this is one. It's easier to take the trail than break your own.
    • jasonjei 9y ago
      Agreed. I don’t see how Docker is slower once the compose environment is setup (especially if you’re running Docker in Linux), and proper volume mounts are made to the source files. In fact, I would say developing with Docker will help with deploying to production, because you’ll be able to see how the app will work in production. I can see Docker being slower if virtualized, but on Linux, it’s just a fancier BSD jail, no?
  • acdha 9y ago
    Yes: Docker adds an enormous amount of overhead. Instead of your Python code you now have to manage a second operating system for the host (including things like not being able to debug or edit directly, having to debug networking, etc.) and whatever OS + deployment is happening in the actual container. For deployment, Docker solves a lot of problems but there's a significant cost for local development.
• natch 9y ago
  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 tools from this post. I’ll need to read up on the tools too. Any pitfalls with this approach?
  • sreevisakh 9y ago
    Just in case you wish to retain anaconda, you could simply remove anaconda path from your PATH variable in .bashrc file (Assuming you are on Linux). If you need anaconda again, you could add the path to the variable, or run `source ~/anaconda3/bin/activate`
  • guitarbill 9y ago
    I think you could probably use both, side-by-side (but not at the same time/for the same project). Anaconda might be nicer if the packages you need are C-based and would need compiling on your platform. Depends on your use-case. For experimentation/playing around, stick with what works for you. But if a project required me to install Anaconda, I wouldn’t take it seriously. And pipenv is pretty easy to use, too. So if you plan on distributing it or open-sourcing it, understanding how most other people manage dependencies ouside of conda is going to be useful.
    • stared 9y ago
      Why not seriously? Many data science environments are pretty much based on Anaconda installations. (See e.g. these dockers: https://github.com/jupyter/docker-stacks/tree/master/scipy-notebook https://github.com/jupyter/docker-stacks/tree/master/scipy-n...) I mean, all packages I know DONT require Anaconda. But if you need the whole environment, sometimes Anaconda is the easiest tool too install all dependencies.
      • guitarbill 9y ago
• MarcScott 9y ago
  Since 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.
  • nextos 9y ago
    Nix is one of the most amazing things created lately. IMHO, it doesn't get the attention it deserves as it provides great solutions to really tough problems and it's ready for prime time. A purely functional package manager, distro, devops. And pretty soon, home directory management. Maintaining servers or doing aggressive changes becomes very easy. There's even a Darwin (macOS) implementation now, so you can manage most of your Mac functionally (with heavy usage of defaults under the hood). It's still lacking a bit on usability, as some things are not as intuitive as in a simple imperative distribution such as Arch or Alpine. Especially if you need to run some prepackaged software that assumes FHS and binds dynamically to some pre-existing dependencies. But to me, right now if you are a moderately advanced user I don't see a point in running distros that are stuck in the middle (imperative, complex, lots of defaults). It's either one extreme (simple and imperative, e.g. Arch) or the other (functional, NixOS).
    • thepratt 9y ago
      I'm a big fan apart from how they version. Depending on when you install the version will point at a different commit hash. In our case, all of our Haskell builds failed on all but 1 machine (day apart in resolutions). How nixos handles environments meant our large package builds would kill the entire os, or underlying lib linking just failed - never figured out why, but it wasn't worth investing more time.
      • nextos 9y ago
        This is one of the usability problems they have. There are some simple solutions to this, but it should be more straightforward.
• GrumpyNl 9y ago
  Im old school, i just install xampp and im ok.
• foobarandgrill 9y ago
  >Why? pipenv handles dependency- and virtual-environment-management in a way that’s very intuitive (to me), and fits perfectly with my desired workflow. Why specifically do you use it instead of virtualenv (+virtualenvwrapper)?
  • sametmax 9y ago
    pipenv combine pip and venv. It's not just about activating. If you install, it will create the virtualenv if it's missing. It also, like pew, opens the virtualenv in a new shell instead of activating the current shell. A much saner approach. The UI is also more user friendly: one entry point for everything, pretty colors and icons, auto-correct of package name, and so on. Using Pipfiles, instead of requirements, are generally a better experience than requirements.txt since it contains dev and prod dependancies and allow separated dependancy pinning, with file hash.
    • gonvaled 9y ago
      Does it install and manages different python versions? Pyenv does
      • mwarkentin 9y ago
        If you have pyenv installed it can use it to install the correct python version defined in the Pipfile.
  • acdha 9y ago
    I was recently explaining this here — you still end up with a virtualenv so it's not a difference in capabilities but rather ease of use: 1. It transparently creates the virtualenv for you 2. The pipfile format handles dependencies and version locking (including hashes of packages), including updates. That means that the versions won't change without your knowledge but upgrading to the latest versions of everything is simply running "pipenv update" to have the virtualenv completely rebuilt (i.e. you'll never forget to add a dependency to a requirements file) and the lock file updated so the next time you push your code the same versions you tested are certain to be used. 3. It'll automatically load the .env file for every command – i.e. your project can have "DJANGO_SETTINGS_MODULE=myproject.site_settings" in that file and you will never need to spend time talking about it in the future. 4. It separates regular and developer dependencies so you don't install as much on servers 5. "pipenv check" will let you know whether any of the versions of any of the packages installed have known security vulnerabilities 6. Pipfile also includes the version of the Python interpreter so e.g. your Python 2 project will seamlessly stay on 2.7 until you upgrade even if your system default python becomes 3. None of this is something you couldn't do before but it's just easier. Every time a Python point release happens you have to rebuild a virtualenv and now it takes 5 seconds and no thought.
• mmsme 9y ago
  Pyenv looks great! Sad I didn't know about this sooner, though I do have the luxury of using mostly one version of Python and have only confused it for the system Python once or twice.
  • symmitchry 9y ago
    Pyenv is great. On our Macs we've had zero issues installing older, specific versions of Python, every time. Highly recommended. (Getting it working properly with zsh was a bit frustrating, but that's my own fault.)
    • tinymollusk 9y ago
      Do you know if it's easy to start using pyenv with existing projects, or should I wait until my next de novo project?
      • bobwaycott 9y ago
        It’s pretty easy if you have a set of requirements handy and have `pyenv-virtualenv`: $ pyenv virtualenv 3.6 some-name $ echo some-name > /path/to/project/.python-version $ cd /path/to/project $ pip install -r requirements.txt That’s it.
    • ddavis 9y ago
      Curious here... why would you use it over just venv (assuming python3)?
      • tomku 9y ago
        Pyenv is a different thing than venv, it manages versions of Python itself rather than isolating dependencies for projects. You're probably confusing it with pyvenv, which is Python 3.4+'s command-line interface for managing venv-compatible environments.
  • donarb 9y ago
    pyenv is really great. The ability to switch environments merely by cd'ing into the project directory is a life saver.
• dangerboysteve 9y ago
  Would it be easier to use individual docker containers, each their own python environment and then have your source directory mapped to a docker directory?
  • kstrauser 9y ago
    pipenv makes it pretty trivial to get the same effect but without Docker. It also means that your favorite dev tools have easy access to the code you're working on.
  • odonnellryan 9y ago
    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.
    • jordic 9y ago
      i use docker for all the related services.. postgres, redis, solr, zeo... but i use virtualenv and pip. I also use setup.py for declaring entrypoints and coordinate all the services (i don't like too much the docker compose aproach). also i'm using docker.py and boto3 for the devops part.
• nravic 9y ago
  Mine is comparably simpler. Emacs + Elpy, and I just pip and pyenv for managing packages. Granted I don't deploy
• twexler 9y ago
  What seems to be missing in the comments here is the `--user` option to pip. Lets you install modules on a per-user basis, doesn't mess with system python. All you need to do is add the bin folder this creates to your path.
  • jonwayne 9y ago
    pipsi installs into isolated virtualenvs, then symlinks into `~/.local/bin` just like `pip install --user`. Combining pipsi for cross-project tools (tox, twine, nox, etc.) with pipenv for project-specific packages is all you need. You don't need to `pip install --user` some package at that point.
• purplezooey 9y ago
  Seems like you could get all this done with conda. Just a thought.
  • odonnellryan 9y ago
    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.
• avip 9y ago
  I don't understand this at all. It's 2018. My dev. env. for <insert thing> 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.
  • odonnellryan 9y ago
    So you're using Docker instead of virtual environments? I feel there is much more overhead with Docker, but I could be wrong. Maybe I need to try it out again!
    • scaryclam 9y ago
      No, it's pretty much the same as you remember it. Using docker instead of just a normal virtualenv is overkill.
      • falcolas 9y ago
        Overkill - Yes and No. Yes, because you are spinning up a full VM to run a docker container locally. No, because the container is also the container run in prod, with no opportunity for some other process to come along and hose your otherwise clean install. The process and FS isolation also make sysadmin-me all tingly inside. That way you can't hose up anybody else's clean install either (even if you're compromised). As a side note, on mac, the VM that runs docker containers requires less ram and CPU than Hipchat. Go figure.
        • odonnellryan 9y ago
          I'd never deploy more than 1 client to a machine anyway, so isolation in a security sense does not make much sense to me if I'm being honest. But I understand. If the workflow works for you and/or your team, well, what's the problem? It's working!
      • mixmastamyk 9y ago
        And virtualenv can be overkill unless you've got multiple clients or legacy commitments.
• goodoldboys 9y ago
  as 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
  • is0tope 9y ago
    Absolutely. Though i have yet to have the chance to use it at work (large enterprise), it has totally been a game changer for me in terms of creating side projects in dev and seamless deployment. There is definitely some overhead and not everything plays nice all the time, but the thought of going back to running 5+ terminal windows / installing databases globally makes me shudder.
• nickjj 9y ago
  I'm a big fan of using Docker because for real world web app development, your app is often more than just getting Python and a virtualenv set up. Earlier this week I wrote about the pains of setting up a Python development experience without Docker, and then compared it to Docker as well. If anyone is curious, that's located at https://nickjanetakis.com/blog/setting-up-a-python-development-environment-with-and-without-docker https://nickjanetakis.com/blog/setting-up-a-python-developme.... By the way, I would say Docker is anything but slow. I get near instant development feedback on my Flask applications, even when running things through Docker for Windows / WSL. These are pretty big Flask apps too, which have thousands of lines of code, dozens of packages, tons of assets and require running Celery, Postgres, Redis, etc..
  • Spiritus 9y ago
    My problem with using Docker (only) is that it doesn't translate well to editors. Like, using jedi-vim[1] with a virtualenv constructed by a Docker container doesn't work at all. Unless I actually run vim itself inside said container. So unless your dependences build on macOS (like in my case), everything goes out the door. [1] https://github.com/davidhalter/jedi-vim https://github.com/davidhalter/jedi-vim
    • AlexCoventry 9y ago
      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.
      • cat199 9y ago
        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 bothersome (not so bad actually, but have to set a separate interpreter path to something like 'docker exec -it ctid python' would like to track this down I suppose
• cup-of-tea 9y ago
  I've been using a similar setup which I found online [0] when I was looking for a way to have multiple Python versions including working Jupyter notebooks etc. It's been working great for me. Pyenv and virtualenvwrapper are really good. I'm not sure why this one needs pipsi, though. You can install CLI tools for both Python 2 and 3 using just Pyenv as demonstrated above. [0] https://medium.com/@henriquebastos/the-definitive-guide-to-setup-my-python-workspace-628d68552e14 https://medium.com/@henriquebastos/the-definitive-guide-to-s...
• oh-kumudo 9y ago
  Virtulenv + Pycharm, 3 years, happy as ever. For ML/DL stuff, Conda is also highly recommended.
  • jordic 9y ago
    same here. Also I'm quite happy about the level of integration between pycharm and frontend things (eslint, babel, react...) I never have to switch editors again. I trend to have a bash script for sourcing node versions... setting the correct path for node binaries, activate the env... and a makefile for building dockers, I try to mantain all the tooling reproductable on the project source.
• yorby 9y ago
  > and Linux (well, Linux-ish - actually it’s WSL) at home. Is that really considered Linux at all? I would not say that Wine is Windows, for example.
• linuxftw 9y ago
  I prefer virtualenv + pip. I primarily develop on Fedora which ships both Python 2.7 and Python 3.6. pip and virtualenv are built into python3, no need to install anything. Additionally, these tools + tox are commonly used for python testing in popular python projects [0]. I have found other colleagues that use other tools struggle with pip and virtualenv, and it puts them at a disadvantage when it comes to working with the larger python software community IMO. [0] https://github.com/pallets/flask/blob/master/.travis.yml https://github.com/pallets/flask/blob/master/.travis.yml
• zbentley 9y ago
  > I use multiple OSes: macOS at work, and Linux (well, Linux-ish - actually it’s WSL) at home. This is pedantry, and the article is otherwise quite informative, but describing WSL as "Linux-ish" is like describing a speedboat as "car-ish" because they both happen to have steering wheels. WSL is a bloody marvel of engineering, but it is in no way an equivalent of Linux. I'm mentioning this because WSL proponents and detractors tend to miss the fact that understanding those differences is critical to understanding and using--even in trivial ways--WSL itself.
• lotyrin 9y ago
  I want a GUI for polyglot local development for cloud-native apps with a variety of backing services that's as braindead and easy as *AMP apps were in the bad old days when you'd be slinging PHP, (plaintext) FTPing up to a shared host, working with guys for whom "server stuff" was pulling teeth and only having one version of Apache, PHP and MySQL to worry about (old terrible ones). This seems within reach finally due to where were are getting with containers and orchestration. A bloated electron app plus kube in a VM maybe? Even that much RAM is still cheaper than my time. Dropdowns for picking out what runtime, what language, what database, what cache, etc. picking where my code lives, then it boots everything up, solves a local hosts entry + ssl cert and keeps my code synced. I should be able to huck my macbook in a wood chipper to protect my private keys from terrorists, unbox a new one, install my Jetbrains Toolbox, install this thing, and be back up and running fixing responsive text wrapping "bugs" on my marketing landing pages in minutes. I should be able to hand my git repo to a potato whose wish to become human was granted by a fairy yesterday owing to their exemplary potato-like behavior and expect they can get the thing booted up and start blowing up my test suite and arguing with me about indentation in minutes. I should be able to receive news of a cool new framework in a cool new language with a cool new runtime and a cool new database written by angels, etched into crystal tablets discovered in the martian polar ice accompanied with proofs that they are both feature complete and error-free then get going on using these gifts bestowed unto mankind in a brand new repo to write a microservice for filling people's inboxes with unsolicited promotions for male enhancement supplements in minutes.
• raduhek 9y ago
  I didn't manage to get a run at pyenv, pipsi or pipenv, but for virtualenvwrapper and tmux work great together. I'm running linux at work and usually keep it alive for days, so tmux is used for session keeping and remote work. I've created a few bash scripts which run some tmux commands for setting up the layout as I want it and also execute "workon" for the specific virtualenv. For working on a new project, I've another bash script which I run with the repo url and automatically clones it, creates the virtualenv with the same name as the project, installs dependencies and starts a new tmux sessions with two panes in first window and a second window for other stuff. The great thing about tmux for me is it's low memory footprint so I can have 10-15 sessions running at a time, without worrying about the computer slowing down. What takes a bit too long is setting it up again upon a restart.
  • foobarandgrill 9y ago
    >What takes a bit too long is setting it up again upon a restart. Have you tried this tmux plugin? https://github.com/tmux-plugins/tmux-resurrect https://github.com/tmux-plugins/tmux-resurrect I use it all the time at work and at home
• brailsafe 9y ago
  Thank you St. Patrick. I recently tried to install an ancillary python based cli tool and realized my python dev environment on my mac is fucked.
• sswaner 9y ago
  It it considered best practice or advisable to run production deployments in a virtualenv? I have always considered it to be a tool for managing multiple development efforts on the same machine, not as production environment management.
  • mixmastamyk 9y ago
    Many prefer it, though it may be considered redundant in a container.
• mychael 9y ago
  This seems more like the 2008 Edition. You have to be pretty stubborn to not adopt Docker in 2018.
  • throwawayfinal 9y ago
    If you're building a native python application, there's no reason to adopt yet another technology. A native python app in "Docker/Containers" is going to look like a dockerfile that includes a copy of the app and runs three commands. Either you build that on the server (what's the point) or use a registry (additional complexity for little benefit).
• collyw 9y ago
  This would have been useful if he compared them to virtualenv, which as far as I am aware is still the "standard" way of managing python environments. I tried virtualenv wrapper a while ago, and that was basically just another set of commands to do the same thing as virtualenv. Having already learned virtualenv command that gave me no real advantage. Are any of these tools mentioned any different?
  • speedplane 9y ago
    Does virtualenv handle different python versions? My understanding was that it just handled different sets of 3rd party packages.
    • vivan 9y ago
      Yes, you can make virtualenvs with different Python interpreters.
• speedplane 9y ago
  The first requirement in the article: > I need to develop against multiple Python versions, including 2.7, various Python 3 versions (3.5 and 3.6, mostly), and PyPy. The article states that this is an "unusual" setup, but unfortunately it is all too common. The Python 2/3 split has created such a large and sad schism in the development community, has wasted countless developer hours, and has held back the language itself incalculably. A travesty.
• vagab0nd 9y ago
  Forget python development, why is it so damn hard to USE python scripts in a version-correct way in the first place? I have python scripts in my system which rely on different python versions. And since I have a default python version, 2.7 (through symlink or env or whatever), all the python 3 scripts fail until I switch the default version manually (due to library dependencies, print format, etc.). Why don't these scripts add "#!/usr/bin/python3" at the top? And why is it so hard to just have 2 versions co-exist? I MUST be doing something wrong here? EDIT: "python3 <script.py>" doesn't always work because some scripts are written in bash and they call python within the script.