i love the textured background , just needs some work-in-progress.gif

the more the deviate from the BSD core the worse it gets.

But I can still fire up a terminal and use all of my *nix skills to operate.

I can't do that on Windows without either wrestling with PowerShell or WSL2

this seems like a huge reinvention of jupyiter , i really hope they aren't going to recreate all the bugs.

I think one major difference between spreadsheets and Jupyter notebooks is state/dependency graph. In a notebook, cells don't depend on each other. They can be run many times, and the order they're run in matters. This is one of the major gotchas with notebooks. With spreadsheets, they're generally deterministic. There is no notion of "cell order", cells are recomputed automatically depending on the dependency graph between the cells. This results in a pretty big user experience difference.

But according to other comments here, that's unfortunately not how this spreadsheet program works.

Yes in that it doesn't appear to use a dependency graph to track recomputes; it recomputes everything on a cell change (according to another commenter anyways). But the UX effect is still the same in that the user never has to think about cell order, and every cell is always consistent with each other.

stop trying to use the system python for application development. You will break your OS and you will make your code machine specific. Go read up on Virtual Envs , you were the problem here.

Python has like a dozen competing solutions in their package management space. Python is clearly the problem, not the user.

Their docs don’t say that, they advertise exactly what the GP ran. Python needs to unfuck its ecosystem.

Yeah they kinda screwed the pooch on that.

That being said, venv is the official solution, and it works fairly well. pipenv/pipx are some alternatives...but yeah.

What exactly is your system installation for if you aren't supposed to install anything to it? The package system should be able to attempt installing via venv or be able to block uncompatible packages with sane error messages.

And for the lazy ones, pipx uses Virtual Envs and can install most things from a path, an archive or a package name. Install pipx and check pipx install --help.

If venvs were a reasonable solution here, presumably the pyspread authors would have included them in the installation instructions. Instead they just say to "pip install", which predictably does not work for most people. It sounds a bit unfair to tell someone that "they're the problem" when they followed the official installation instructions to the letter. I would agree in classifying this as another case of python developers being unable to provide a working way to install their software (if code that the average person can't even get to execute can even be called "software".)

venv not always a panacea for system python

  $ docker run --rm -it python bash
  [...]

  root@211646f0fa99:/# which python
  /usr/local/bin/python

  root@211646f0fa99:/# python -m venv .venv

  root@211646f0fa99:/# source .venv/bin/activate

  (.venv) root@211646f0fa99:/# which python
  /.venv/bin/python

  (.venv) root@211646f0fa99:/# ls -l "$(which python)"
  lrwxrwxrwx 1 root root 21 May  7 14:47 /.venv/bin/python -> /usr/local/bin/python

Correct, virtualenv isolates package installation but doesn't handle installing or managing arbitrary Python versions.

Node.js is similar with npm.

Is there something like nvm but for Python?

Try pyenv - very handy, includes funkier editions like pypy

Why is this directed at me? I'm not the one doing the software development, I was just trying to install an application.

> stop trying to use the system python for application development.

Umm... who exactly makes sure the app runs correctly with the version of python installed by the system?

I, for one, aren't going to bump up a python version to run a single app in a virtual environment because some dev decided to use 'python nightly' to code against.

As programmer you should be confident that your code works but for an business you need more than that, you need to prove the code and the assumptions you make with it so that it is safe to rely on.

Good programmers understand that tests allow them to move on safely to the next thing, as professional if you are not doing this you are creating technical debt.

It feels like your analysis is based on having to add tests without enough support from a skilled tester who is empowered to drive testing, if the tester is just told to rubber stamp code without delaying deployment they wont be able to do much. Thats not really the fault of the tester that is a choice to deprioritise test.

these are good insights.

As nerds we tend to only look at the specs and get bored when it comes to how the product is marketed and supported but this is a huge factor in development of these products. If they don't have clear obvious use cases they will be much much harder to sell. We are maybe 1% of the marketplace, the difference in revenues between 1% market coverage and 90% is massive, hardly anyone can run a business making perfect products for 1% of market

yeah this is a autopilot problem which comes from the fact that in car electronics are universally badly engineered. Just have a look at any talk about automotive security research.