Using Vim as a Python IDE
liuchengxu.org
liuchengxu.org
Well, for all of their benefits Electron apps in general have some hiccups on resource constrained systems.
Edit: realized you're probably talking about vscode, which is an electron app
That being said I've used PyCharm on a system with 2 GB memory before and that does work okay, you just need to make sure that no other memory-hungry apps run at the same time (browser, email, multimedia) and that the system itself doesn't use too much memory.
Also, Visual Studio has been around since 1997 and there's no reason to assume, out of hand, that VSCode won't last as long, being both popular and Open Source.
I'm a Vim user, but cut the FUD.
Ctrlp, python (the filetype plugin), vimwiki... most of them honestly.
> You can't compare naked Vim with VSCode.
If you're doing C programming, it's probably close to equivalent out of the box. For Python development, you'll want to at least get the Python plugins; but you'll be doing that in most editors.
IMO, VSCode is interesting, but it's not that spectacular if you've been using any form of IDE (or a decent text editor with plugins). That is, it doesn't offer any major advantages over the other editors.
The base editor is open source but you can get the full PyCharm for $99 per year. Worth every cent.
The only thing I've found PyCharm good for is doing other functions, like linting, not for the actual code editing. No IDE is any good for that. Luckily, PyCharm works just fine when the code it's working with changes on the filesystem below it because of the use of an external editor.
I've never found I needed to use a GUI for developing software, outside of a browser.
To be fair, most other mainstream languages (except maybe Go) lack that kind of tooling too, but at least their cultures do not encourage liberal use of deeply nested directory trees and overengineered abstractions, the way Java does.
With respect to vim, at the primitive end of the spectrum is ctags. At the opposite end there are things like the fabulous vim-go, which provides all the functionality that you'd expect in a traditional IDE. There are many similar plugins for other languages.
Regardless, I contest the idea that you have to use an IDE. I find traditional UNIX tools more than sufficient for programming in any language. I can find definitions with grep, use ctags and vim's chugger to manage definitions across many files in many directories. I'm also not limited to the scope of just one project. The tools I use and my expertise with them can then be applied to any language or problem. I use the same tools to write emails and commit messages.
Large legacy Java programs may be frustrating, but they're not all that bad, and certainly don't warrant requiring maintainers to learn and use an IDE.
Yeah, nobody does that. Well, nobody who has any kind of serious operation going on.
If you can't replicate a bug outside a production environment you have a serious deficit in the devops department.
You should be able to stage a machine with a copy of the production DB/data and the same reproducible package(code) that currently runs on your production systems.
Everything else is just an accident waiting to happen.
> directly on the production system?
Why does 'non-local' have to equate to production? Are you able to use an IDE in your container/VM/cloud server?
My host system is Fedora but since our production code is deployed on Ubuntu, I have a Vagrant Ubuntu image. PyCharm reads the Vagrantfile and it has access to the virtualenv(python in our case) of the Vagrant's image.
UPDATE: I am not sure if that's what you were asking. Maybe this response(https://news.ycombinator.com/item?id=13543158) I gave is more relevant ?
But in general this is my(our) process.
- First I write the code.
- Then I test the code locally.
- Then I test the code on an instance with a copy of prod data. If I want to debug at this point, I run the web process locally while my DB configuration points at that specific server with the prod data.
- If it's code that spans across more than one subsystem(e.g. it also involves async celery task/queue servers) I test on a staging environment, that duplicates(as much as possible) the prod infrastructure.
- Then I deploy.
Obviously there are other various details, plus rollback plans in case something still goes wrong, but that's the gist of it.
I believe it's possible that nobody ever logs into any instances in the staging environment, but if that's the case then your organization is an exception to the rule. Plus you mention it's "as close as possible" to the prod infrastructure rather than identical.
The point is: don't act superior by feigning ignorance that most shops still have people who occasionally log into Linux hosts.
I said we never directly change code on production because it's bat-shit insane. That's why this thread was started. You can trace it back.
I never acted superior, but I really don't get the "me and some people I know do this so everyone must be doing it". No they're not.
And what I described in all my responses (not just to you) can be scaled down to this:
1) Do you know how to install a Linux machine?
2) Do you know how to install a DB?
3) Do you know how to take backups of your DB?
4) Do you know how to change your DB's config so that it points to other machines?
5) Can you write a shell script no more than couple lines?
You answered yes to all of the above? Then congrats you can already do what I'm describing. Yes, you can go crazy later with configuration software(ansible/puppet/etc) and better infrastructure, but the above will suffice as a first step.
So all this "haha, this guy is in his own SV bubble, haha"... yeah really not getting it, sorry.
Uh, what bubble are you living in? Almost everyone does that to some extent. We can all pretend we're code ninjas with super clean deployment pipelines and strict policies, but all of us get lazy occasionally.
No they don't. I am not living in a bubble. You're describing a mom and pop shop.
And by the way you don't have to be a code ninja or have a super devops team for that.
You can have your code locally, point your DB config to a staging server with a copy(you do backups daily, don't you?) of production and boom!
Seriously now... elementary stuff. If you're still changing code directly on live systems you have a long way to go.
What I describe is not out of a management textbook. This is really really elementary stuff if you want to sustain any serious operation.
Let me explain: so you're saying a customer is on fire. Let's say that a query generated by that customer for some reason it creates a spike in your DB. Let's say that it almost DOSes your system. You know it doesn't happen locally, with your dummy/fixture data and it doesn't happen with other users/customers. So some particular configuration of state(your DB) is creating this problem. What are you gonna do my friend? Retry the query on production while you have a debugger on the webapp process? Please... be serious.
Remember, it's only once you have to setup this kind of infrastructure(and you can scale it up or down depending on your resources). And then you can do business like a normal person. What you describe is like throwing my sanity out of the window every time there's a severe(or not) support issue ticket. It doesn't scale!
The only place I can see this never happening is in large enterprises that have huge departments with slow enough turnover that "the accepted workflow" is easily passed on to new hires. Referring to everyone else as "mom & pop shops" makes it sound like the speaker is living in a Silicon Valley enterprise bubble.
I find it amusing to see that term used as an insult on a site largely populated by startups.
Also a startup doesn't necessarily have requirements for serious ops, but it may, some day. Well if they want to be an enterprise at least. You do know what the goal of a startup is, don't you?
And btw, no I don't live or work for company in SV. Europe mostly, with a dash of Dallas, Texas in the mix.
In any case, I was hoping for engineering arguments, not personal attacks. :(
He edited the code live on the production server sometimes. And he did it in the repl, not by editing source files, so he didn't even have a record of what he changed that could go into version control.
When you're nimble and you need every advantage to compete, sometimes you have to be able to do things the hard way.
Not that I would recommend it; every ethical programmer in the galaxy has denounced the practice. And they have good reasons.
If I need to do something significant, i'll scp the file around. I know vim can edit over ssh, but I honestly never do.
I've never tried vscode, but I am tempted to try the remote support: https://github.com/DonJayamanne/pythonVSCode/wiki/Debugging-...
In ubuntu it's file -> connect to server -> type in ssh://username@ip
That's it you are done. You can now browse the files as if they are local and use sublime/gedit/VSCode/Pycharm/whatever you want
sshfs -o Ciphers=aes128-gcm@openssh.com -o Compression=no -o reconnect \
-o modules=iconv,from_code=utf-8,to_code=utf-8-mac \
myremote:/somedirectory/ /mylocalmountdirIf you want to read about this topic:
rsync: http://askubuntu.com/questions/533690/rsync-with-special-cha...
But sometimes there are merge conflicts. I've settled for xpra and kdiff3 as the mergetool. I just can't handle the problem without a GUI tool.
I still keep vim around for huge files though. I work daily with NASTRAN input and output files, routinely multiple 100 mb, sometimes multiple-gb. I edited a 10gb file earlier this week and vim didn't choke up too much. Best editor I've found so far for huge files.
#+name: data-table
....
#+name: process-data
#+begin_src lisp :var data=data-table
...
#+end_src
#+begin_src gnuplot :var data=process-data
...
#+end_srcThis is one of the longest-standing line in my vimrc so far:
Plug 'epeli/slimux'
The superior solution you are looking for is the package called elpy.
It provides this, linting via flycheck, contextual auto-completion via company-mode, etc etc.
I wouldn't know how to survive without it. It's almost a full IDE in itself.
I have a nice 'generic-eval' operator in evil that lets me select via motions and eval the result. This is the best experience I've found so far. Documented here: https://gist.github.com/ad2b435bfdf2ec5f0b4d57aa8ea40df6
[0]: https://github.com/jzelinskie/dotfiles/blob/master/.vimrc
[1]: https://github.com/jzelinskie/dotfiles/blob/master/.zshrc
Even though I write ruby and javascript all day, I still like to go and read how others are using vim. I usually walk away with a keybinding or plugin that makes my life better.
For the most part, when I need this, I revert to Rodeo (since it has vim bindings like RStudio's), but if I could ditch it that would be amazing. Nothing against Rodeo or other editors, but vim habits are hard to break.
I admit I have never used Vim or Emacs but the tutorial was enough to do movement and I also read this wonderful documentation as well: First this here which gives a wonderful overview of the whole philosophy behind SpaceMacs:
http://spacemacs.org/doc/DOCUMENTATION
Then I took a look at this just to get some better idea of how to do certain things with the layers since it's very dependent on a layering system:
http://spacemacs.org/doc/LAYERS.html
And for good measure since Evil mode emulates Vim I thought it might be nice to see what this had to say:
http://spacemacs.org/doc/VIMUSERS.html
It took me like a week to be efficient but now I'm flying so much faster than I was with VS Code or Atom. I still use Sublimr Text for some things because I like it but this is a great editor and has a lot of potential and is extremely extensible with Emacs lisp and I believe they already have a way to bridge in Vim plugins too
Screen is a similar program.
I use a macbook pro with iterm2, and I prefer to use a terminal multiplexer instead of tabs or the native screen split of iterm2.
If you ssh remote boxes a lot, it is very useful because you will not lose your session in case of an occasional disconnection.
ssh hostname -t "tmux -CC attach || tmux -CC"
Not to mention you can share your command line shell session/screen with other people!!
tl;dr, use tmux if you ssh into places and hate restarting after losing your connection.
Using tmuxinator, I might set up a config for a rails project, for instance.
That way when I start tmux I get a vim editor in one window, a bash prompt in the next (for git), a rails server in the third, tests in the fourth, maybe another process in the 5th like sidekiq or something if required. Note, these (tmux-)windows all live inside of one terminal window.
So once you spend about 2 minutes writing that config, you can always start up your environment with tmuxinator start project-name and a few seconds later you're good to go.
Man. https://linux.die.net/man/1/tmux
Or if you're not into the whole brevity thing: https://linux.die.net/man/1/tmux
Try it with a friend the first time.
That's why, while I use VIM when I have to, I much prefer the technology to handle automatically whatever it can. Like maintaining states, making them obvious and offload any fruitless decision making.
I also really like you "space-vim" project. Another similarly named project — "SpaceVim" http://spacevim.org/ — was posted recently. "SpaceVim" was really upsetting because it missed so many of the important ideas of Spacemacs, such as pneumonic keybindings. "SpaceVim" is a garden variety vim distribution coopting the "Spacemacs" name, but you stayed true to the "Spacemacs" principles. Nice work!
The maintainer of the competing "SpaceVim" project I mentioned just opened an GitHub issue on my personal dotfiles repo to spam me with his project: https://github.com/superquest/dotfiles/issues/1
Bizarre.
I think that's the first time I've ever gotten a personal email because I starred someone else's repo!
why I create SpaceVim, instead of support space-vim, I think space-vim is just a copy of https://github.com/ctjhoa/spacevim and https://github.com/Tehnix/spaceneovim-layers and https://github.com/Tehnix/spaceneovim
BTW space-vim's some syntax script is copy from https://github.com/junegunn/vim-plug and install script is just copy from spf13.
so I do not want to support it, but when I create SpaceVim, and post blog anout SpaceVim, the author of space-vim comments a lot of unfriendly message.
and here is the link.
so I will apologies to all the people who receive my emails about SpaceVim, but I will not apologies to the author of space-vim.
I'm talking the full shebang.
* Autocomplete/Autoimporting (Static Analysis backed by compiler output)
* Formatting
* Linting
* Fast or able to run over a slow SSH connection.
* Default error resolutions (if test() throws an exception generate a try { })
* Global refactoring
* The idea of a project (Creating, building, export/importing, libraries, dependencies)
* Automatically generated & maintained building system at the click of a run button
* Documentation at a single click or on hover if possible
* Integrated console for running a project
* File and source manager that should be easy to use
* Binding profiles for Eclipse, NetBeans, JetBrains, VS20XX, ReSharper
* Formal Method Verification?
* Coloring/styling of the entire TUI
* Simple to interact with menus
* Rust, Go, JavaScript (Browser & Node), Java, Scala, C, C++, PHP, Python support
* Pluggable language support that allows the plugin to provide static analysis & compiler data
Project grouping in the traditional sense can be done with projectile and NeoTree. http://projectile.readthedocs.io/en/latest/ https://github.com/jaypei/emacs-neotree/blob/dev/README.md
I think what you are describing in the second half can be handled with company mode and triggering a major/minor mode off a file extension. https://www.gnu.org/software/emacs/manual/html_node/emacs/Ma...
If that's not it it's possible Googling will find exactly what you describe. People tend to port anything useful from any editor to emacs.
[TYPECHECK]
ignored-modules = ssl,pyodbcAdd it to your `ftplugin/python.vim`. Requires you to have activated the Conda environment before opening the Python file, uses hard-coded Python versions, doesn't work with multiple environments, doesn't bother with `os.path.join` so no Windows compatibility, etc etc. Like I said: a hack.
" Cheap trick to use the Conda environment with omnicompletion
python3 << EOF
import os
import sys
cenv = os.environ.get('CONDA_PREFIX')
if cenv is not None:
# Taken from `sys.path` as reported by ipython
sys.path.insert(0, cenv + '/lib/python3.5/site-packages')
sys.path.insert(0, cenv + '/lib/python3.5/lib-dynload')
sys.path.insert(0, cenv + '/lib/python3.5/plat-linux')
sys.path.insert(0, cenv + '/lib/python3.5')
sys.path.insert(0, cenv + '/lib/python35.zip')
sys.path.insert(0, cenv + '/bin')
EOF
set omnifunc=python3complete#Complete
Finally I gave up and moved to NeoVim and have no issues with my vim anymore. Maybe later I will give another try to spacevim or emacs. Maybe. So far, keeping my fingers safe :D
Every so often when vim irritates me I try out PyCharm or vm-whatsit, and while IDE's do have better viz for some use cases, the actual act of manipulating code in-buffer never comes close to speaking vim. And I always add the vim plugin, without them the tool would be of no use to me whatsoever.
I hope someday some tool will eclipse (no) vim, but that's simply not the case in 2017.
PyCharm - No good vim emulation for editing
Spacemacs - Soft locks, Ctrl-] doesn't follow the same word boundaries as Meta-. (which matches Vim's implementation)
Sublime Text - Closest fit (enough that I own a personal license), but again, the vim emulation is pretty bad.
Atom - Slow. Even at its fastest, it's noticeably slower than Vim
VSCode - Slow (though faster than Atom), no good vim emulation.
Yes, most of my criticisms form around the lack of good vim emulation - my muscle memory is very well established. I've just yet to find a good, responsive, and comfortable editing scheme from a non-Vim editor.
I recently switched back to doing Java almost 100% of the time and have been using IntelliJ. There are definitely a lot of Java-specific features I use very heavily that I wouldn't be able to get without a lot of of time and plugins in Vim. But sometimes I hit weird bugs that highlight the relative complexity of the core, and I often feel frustrated by how light-weight it isn't (granted, I've tried some other Java IDEs and it's amazing by comparison).
But I used to work more with various scripting languages, and my gvim setup just couldn't be beat. So light-weight, but easy to set up again if I needed to. Still able to navigate code structures, debug without context switching. I often did something with a partner that amazed them, because they couldn't do it with their IDE; my favorite thing in the world is the look on someone's face when I select a rectangular section of text and change the indentation without affecting the stuff on the left. It was incredibly productive for years. I still occasionally go back there when I'm working in a single Java file, because the vi emulation mode in IntelliJ isn't quite there and I can manipulate the raw text so much faster in gvim.
More useful, IMHO, is the general solution of jumping to the definition that would be resolved by the python interpreter, regardless of location. For that, the key binding will depend on the plugin. For `jedi-vim`, you use `<leader>d` [0].
Incidentally, if you're new to using VIM as a python IDE, also note the value of `jedi-vim` providing Python docstrings via the standard VIM keybinding `K`. This is also mentioned in [0].