Comments URL: https://news.ycombinator.com/item?id=44699623

Points: 17

# Comments: 4

Also, TUI's have their place. I haven't looked much at GUI alternatives, but k9s is really great.

Would also assume that interactive apps are simpler to implement if it's a TUI.

We ended up using the REST API for automated provision management and there are certainly warts. It's a far cry from being a turn-key solution, which I'd argue is preferred by a large enterprise.

It's great for click-ops if that's your use case, but that also wouldn't qualify as an enterprise use case.

It's fine, I guess. But it did take a while to learn the new ways.

I think this is the main complaint from users with decades of experience. Their scripts and old knowledge stops working.

I did have a look at numpy and on my machine the tests did not bloat it as much as you made me believe. The `core/tests/` modules are 3MB and the `__pycache__` doubled it to 6MB. What do you refer to as "test case artifacts"? The modules, pycache, or both?

Also, wrt you statement on pandas; is it the debug symbols that account for the bloat, or the libs themselves?

> By default, `args` is a set of derivation names denoting derivations in the active Nix expression. These are realised, and the resulting output paths are installed.

?? - I think the author really hits the nail on the head with this point.

> I think for the ease of installation alone rasterio is a blessing.

How does rasterio simplify installation, when you still have to deal with gdal's C extension dependencies?

Whenever I see a GIS application, I'm always curious to see how they solve the gdal problem.

The best is always no GDAL, but that gets pretty hard to do quite quickly as GDAL contains some really great algorithms for dealing with non-trivial raster processing.

I get why rasterio is preferred, its API is less annoying, but I'm not sure putting a leaking abstraction over gdal helps much. It just creates an aluring veneer over gdal, without really solving the main problems of gdal, being its monolithic monstrosity of hardly portable yet highly necessary GIS tool functionality.

Doesn't matter too much with gdal's warts, as this server should be deployed with ansible or in a container anyways, so portability is handled in a somewhat sane manner.

Thanks for open sourcing this!

Now that the frontend devs have gotten their attention, I hope dgraph plans to give the python community some love as well by improving the client API and asyncio support and even full integration with networkx.