Fix Windows develop install

[vidartf]

Fixes #192.

Reuses certain parts from jupyter-packaging, with some small improvements that I will also contribute back.

[vidartf]

Works now. Note that the existing wrapping of egg_info causes the JS build to be run twice during install. I'd recommend using MANIFEST.in to pick up the datafiles instead, so you would only have to do a single build: https://setuptools.readthedocs.io/en/latest/setuptools.html#generating-source-distributions

[maartenbreddels]

Sorry for the flake8, we should have something in the docs for pre-commit hooks.

[maartenbreddels]

Whow, I find this a bit harder to digest than the solution in ipyvolume, what was wrong with that solution?

[vidartf]

Whow, I find this a bit harder to digest than the solution in ipyvolume, what was wrong with that solution?

Quoting from #192:

The main two points are probably:
- Using which to find the executable.
- Using shell=True or not.

[vidartf]

Regarding hard to digest, note that the which function is just a polyfill for Python 2.

[maartenbreddels]

I still find widgetti/ipyvolume@a434ce7 a better solution that is used throughout most of the widget packages. If that works, and is less lines of code, why should we the which/run solution instead.

These massive setup.py's scare people (including me), which is not good for contributions I think.

[vidartf]

If you want to do it your way, don't ask me to open a PR ;)

[maartenbreddels]

My point was, this little piece of code works for ipyvolume, since you are on windows, it's better if you test it is really working, sorry for being such as pain.

[vidartf]

Ok, thanks for defusing the tension. Let me clarify my position a bit then as well:

In the long term, I think the solution for all of this should be good:

• Once we can reliably assume all users to be on pip>=10, we can have all python packages bundling JS have a pyproject.toml where they require jupyter_packaging.
• jupyter_packaging is meant to avoid all JS building packages copy-pasting the same code in all its various, branching versions. This will put all fixes in one spot, and clean up setup.py code (just import needed functionality). It will also allow us to track what the reasoning is for each piece of code by more clearly following the commit log and issue discussions.

While we are waiting for that glorious future, I'm slowly trying to make as many packages as possible converge towards the code in jupyter_packaging. The main motivation being:

• Easier upgrade once we are able to switch.
• Trying to make sure everyone benefits from the fixes that are in jupyter_packaging.

Some of the solutions that are in jupyter_packaging are a little obscure on the surface. Some of them turn out to have a very good reason once you dig into it, some of them don't (but they rarely cause any harm). I simply went with the solution from jupyter packaging because I believe it has had more eyes on it, and been tested by more people. E.g. I believe the shell=True argument is critical in certain cases on Windows in order to get the correct env.

[maartenbreddels]

Ok, that sounds good. Would you mind opening an issue or putting in some comments when we can remove this code, and maybe even refer to this PR in the code?

[maartenbreddels]

@vidartf let me know if you agree with the comments I put in, if those are correct, then we can merge this.

[vidartf]

LGTM, but flake is complaining ;)