Show HN: Pypipe – A Python command-line tool for pipeline processing (github.com)
pypipe is a command-line tool for writing data pipelines in Python. When working with data processing in the terminal, I often find myself wanting to pass the output of commands to Python for further processing. In such cases, one can either write one-liners or create regular Python scripts and connect them through pipes. However, using pypipe makes this process more convenient and efficient.
49 comments
[ 3.7 ms ] story [ 132 ms ] threadMy tool of choice for such things is awk, still, it's good to have more alternatives
A tool in the same vein that I already use is pyp (`pypyp` on PyPI). This project, pypipe, has built-in record splitting and CSV support that pyp doesn't. CSV is lower-friction. pyp automatically determines what modules to import. It is very convenient and would be nice to have here. A version of `pypprint` (https://github.com/hauntsaninja/pyp/blob/9408446a41bfdc60e44...) may be useful, too.
The most famous Python command-line tool like this is probably Mario (https://github.com/python-mario/mario), which isn't maintained. pyp's readme compares Mario and some other alternatives: https://github.com/hauntsaninja/pyp/blob/9408446a41bfdc60e44.... pypipe is different from most for also having a feature like `--explain` in pyp (code generation).
> However, the lack of prior knowledge about pyp has given pypipe its own unique identity.
This is why I think it is not always bad to reinvent things. Reinventions can have their own advantages, often through a somewhat different focus. There can be value in creating (a prototype of) your own solution before you see how others have solved your problem. (Or even where others draw the line around your problem, which may be different from where you do and override it.) Reinventing and sharing something is also a reliable way to learn about prior art. :-)
However, you usually don't want to be the one doing the reinventing. :-) It is not the best use of one's time and resources. A better starting point is to know the state of the art well and have some disagreements with it.
Let me share a personal cautionary tale. It doesn't really apply to pypipe but may still be useful or interesting. I once took it too far with static site generators. In order to make it a learning experience, I deliberately avoided studying existing ones in depth. I wrote mine in a niche programming language with what I thought was a fresh perspective. (It kind of was. A big part of it was leaning heavily on an in-memory SQLite database.) I repeated the mistakes of early content management systems, like heavy indirection and too much code in templates. Soon my static site generator had users! And I was just realizing how flawed it was. Oh no. The users were few, but they used the generator for real things, like an event. Some knew about my wheel-reinventing approach and weren't dissuaded by it.
I found myself stuck with a subpar design to polish for the 1.0 release. When it was finished, I had to do a fairly difficult and only partial reworking for version 2.0. To encourage moving to the new version and not frustrate those with complex projects, I wrote a migration tool. The most serious projects based on the generator stayed on version 1.x.
So, I advise against going this far. It is probably best to do the research and learn about the state of the art first. I try to do it now.
Again, this is much less of a concern with pypipe. It doesn't create the same kind of user lock-in as a static site generator. At most, you will have to ask your users to upgrade their shell scripts when something changes.
I've been making a lot of tools in this similar vein. I've been keeping them in my dotfiles.
I've got plt [0], a simple matplotlib templating language built with Python Lex Yacc for making quick plots from CSVs , eg,
There's a plugin format so you can make extensions like bleep [1]: To create a plugin xyz, just call it "xyz_template.py" and put it in ~/dotfiles/plt. Outputs to Python code are optional but useful for minor adjustments.(Does plt look familiar? Can you tell I just read the latest version of The Awk Programming language?)
Or I was reading The Unix Programming Environment (1982) and being inspired by the pick command, wired up electron to allow for STDIN/OUT/ARGV in the browser context, for what I'm calling elec [2]:
Again, to create a plugin xyz, and in this case all elec commands are plugins, add "xyz.html" to ~/dotfiles/elec, as seen with the pick [3] plugin.ANYWAYS, where I'm going with this instead of,
How about? Convention over configuration!Again, this tool is great, it's already in my dotfiles and I've already used it at work this morning, so thank you!
[0] https://github.com/williamcotton/dotfiles/blob/master/bin/pl...
[1] https://github.com/williamcotton/dotfiles/blob/master/plt/bl...
[2] https://github.com/williamcotton/dotfiles/blob/master/bin/el...
[3] https://github.com/williamcotton/dotfiles/blob/master/elec/p...
https://github.com/dbragdon1/s3head
and I'm gonna have a good time piping the output from s3head into pypipe.
Also, just to make sure we're on the same page:
The command `ppp` (found somewhere in PATH, unless it's a shell function or an alias, but we believe it's a symlink to `pypipe.py`) receives `pypipe\n` on stdin, sets a variable named `line` to `pypipe`, uses the slice notation to convert that to `ppp` and then prints `ppp\n` to stdout.
Also since you really want to think of this as an extension of coreutils it would be great to offer this as a brew/apt package even if it's this simple. I just want to add it to my system package list and be able to depend on the command.
I think they are worth for more complex apps (I actually have a draft blog post with some experiments I did using PEX + gunicorn), but for my use case, it's not worth the effort when I only need the standard library.
For example,
There is a downside. Because pip-run recreates the virtualenv every time, the script takes a second to start up. pipx will cache virtualenvs once the single-file script feature is released. I haven't used fades yet.Edit: fades caches virtualenvs.
I like to set up at least some tests on my scripts so that I can reduce the number of times I push something out that is obviously broken. pre-commit can also help with preventing shipping things with syntax errors if you enable the "ast" check, which does a simple syntax check on the code.
I've created a package in Wasmer [1] to showcase this tool (also, it will do the processing fully sandboxed thanks to Wasm!)... hope you all like it! (here's the PR [2])
And then, run it normally: [1] https://wasmer.io/[2] https://github.com/bugen/pypipe/pull/2
Compare this to OP's instructions: (1) check out the repo (2) execute the file directly.
Not sure why would anyone want wasmer for simple command like tools like those.
It gives me so much Perl one-liners vibe, when `perl` command combined with `-p` and `-e` flags allows you to write super concise programs for bash pipelines.
Some examples https://learnbyexample.github.io/learn_perl_oneliners/one-li...
[0] https://gist.github.com/leonjza/9d53b30a6b85ff837a27170a185a...
I was going to ask how this differs in broad strokes from pz, but when I went to get the reference link found that pz hasn't been updated in two years, so that's one big difference.
https://github.com/CZ-NIC/pz