ehremo

Yes I have sometimes wondered about that. In fact another aspect of npm which I don't get is if you have multiple "instances" of a library (e.g. different versions, or even two copies of the same version) then any library global variables will not be shared across those instances.

But I don't know enough about JS development to say whether this really happens and/or if it is an issue (some pretty cool stuff has been done with JS so I guess it's possible to live with it).

BTW I share your dislike of hipsters, though I am a bit jealous those moustaches are just so cool.

A caveat of the approach is that you must run the script from the project's folder.

This is apparently an unacceptable limitation for some people, judging by the responses to the article - however for others it's not.

But you may want to keep 3 installation levels: global, per-user and per-project. If you use the second to achieve the third, then you no longer have the second.

Actually I don't believe that would happen. I think the relative PYTHONPATH gets expanded at startup and becomes an absolute path. Subsequent changes to the working directory wouldn't affect it.

Yeah I think for me it's more about the intellectual overhead than performance.

With this you just have one tool, and it's just easier for me to understand what's going on compared with virtualenv.

Well as we mentioned, it's supposed to solve a situation where you don't want to use all the overhead of virtualenv.

The things you care about may be different from what others care about: I'm guessing don't care about Windows compatibility or you wouldn't talk about shebangs, and others may not find only running the scripts from the project root an issue (I don't for example).

Why is a relative path in the PYTHONPATH necessarily bad practice? It's not a rhetorical question, I am genuinely curious.

If you're happy with virtualenv then continue using it - all we have done is propose an alternative.

It doesn't really make much sense to compare xlwings with PyXLL, as they perform a slightly different function and actually could be used together.

PyXLL is more comparable to ExcelPython[1], which is open source does a similar thing (enables you to write UDFs in Python). ExcelPython hosts the Python process outside the Excel process but it

a) does not restart the Python process with every UDF therefore has good performance

b) does not require any registration of COM servers - therefore doesn't require admin rights

c) does not require an add-in (there is an add-in, but it just facilitates development, it's not actually required to use the resulting workbook).

[1] https://github.com/ericremoreynolds/excelpython