fzumstein

DataNitro was my inspiration for the Open Source version of xlwings back in 2014. They have been out of business for many years though.

xlwings creator and author of the O'Reilly book "Python for Excel" here! First of all, big congrats to the team! I've been in contact with the Excel team on and off over the years and I remember when an Excel project manager once described the task of adding Python to Excel as "turning a fully loaded ship". Well, I am happy that the ship has now turned and is ready to ship into more exciting waters! There are a few question marks I have given my decade long experience with the topic (although everything is still beta, so it will certainly change/improve on its way to GA):

(1) I have hardly seen any company that can do with an off-the-shelf Anaconda distro. Companies usually have an internal Python package that they will need to access. (2) When running Python on the backend, the first question is always "how can we authenticate the user"? Office.js is currently the only platform I know of that allows you to leverage Azure AD identities via SSO or use any other provider (as you have complete freedom to use any JS library/redirect the user to a login form). (3) IT policies: Usually, companies have made their cloud decision: “We're an AWS/GCP/Azure shop, so Python has to run on precisely AWS Lambda/GCP Cloud Run, etc.” Yes, many are on Azure, but even in Azure they may have preference of let's say Azure Container Apps or AKS instead of Azure functions. (4) The other thing that businesses are obsessed about is to securely protect their source code, again, not something that Python in Excel seems to support. (5) And finally, what I see users most excited about in the context of xlwings is being able to run standard User-defined functions (aka "Custom functions) on the server (like the ones we wrote in the good old VBA times or like the new Lambda functions), not sure if that's possible or on the roadmap for the official version.

With the modern xlwings Server, I have taken a different approach: Let users build a 100% standard Python web app using their favorite framework (Django, Flask, FastAPI, ...) including all the standard tools (logging, auth, etc.) while using Excel as the frontend. Users have complete freedom in choosing their tech stack, they can version-control the source code on GitHub, use GitHub actions to run unit tests and deploy the code automatically to their favorite cloud, etc.

So I am probably targeting more professional developers than data scientists, but in my experience, it’s often a professional developer who write the Excel add-in that is then deployed to business users/data scientists.

We built https://www.xltrail.com to make Excel work with Git.

I am the developer of xlwings, so this is heavily biased. Anyhow, ever since I’ve added support for Google Sheets, I am building all internal tools with it. No HTML/JS/CSS required whatsoever and everybody knows how to interact with a spreadsheet UI. There are a few sample projects on GitHub, e.g., https://github.com/xlwings/xlwings-googlesheets-pandas-plots (they use FastAPI, but it’s trivial to adapt for Flask). On top, Google Sheets let you easily authorize the user on the backend, so you can give certain users read-only access to a database, as an example.

Hey has! I should have mentioned that xlwings is a wrapper around your excellent appscript package that does all the heavy lifting with AppleScript :) Thanks for reviving the project on GitHub :)

Have a look at xlwings (I am the creator), it’s a Python wrapper around AppleScript that follows closely the original VBA object model, so won’t require a change in mindset.

I found noVNC easier to use.

At https://www.xltrail.com, we wrote an open-source Git extension that allows you to diff the VBA part of your Excel workbooks. The extension also integrates with SourceTree, Atlassian's free Git client. You can see some screenshots on my blog post: https://dev.to/fzumstein/how-to-diff-excel-vba-code-in-sourc...

There is https://gridstudio.io/ but I am not sure what the current project status is...

Thanks for pointing this out and I'll update the homepage accordingly. You're right about the sustainability challenge though!

You're right, it's the biggest challenge. But a ton of companies do now have something like Anaconda in their official software catalogue and sometimes even an internal mirror of PyPI or anaconda.org for the packages.

Book author and xlwings creator here. Thanks for posting this link! Funny enough, about 10 days after sending the book to the printer (March 11), Microsoft updated the feature request ("Python as en Excel scripting language") on their UserVoice page with a comment that looks like official support could eventually happen: "Thank you for the continued interest in this space. While we don’t have specific plans to announce at this time, we have been researching the topic, conducting customer interviews, and are working with the Python team at Microsoft so we can build a plan that we think can address the scenarios you told us about and ensure it can run wherever Excel runs." Fingers crossed! See https://excel.uservoice.com/forums/304921-excel-for-windows-...

not if you don't know anything about css ;)

With Excel (the stuff that tends to be most critical), Microsoft has gone through a few iterations on this. Just a few days ago, they finally enabled a proper Version History on the online version of Excel, much in the same way as it’s been available with Google sheets for years. If you are bound to offline Excel, your options include 1) Shared workbooks 2) Co-authoring 4) Network drive 5) SharePoint 6) DropBox/OneDrive etc. You can get all the pros and cons in a recent blog post of mine: https://www.xltrail.com/blog/collaborate-on-excel-workbooks. I am part of a group of developers so we agree with you on wanting to have “GitHub for Excel” which is why we built: https://www.xltrail.com

I agree with you mostly, but Excel is still often a good choice for reporting. And with a package like xlwings, you can do it all from Python.

If you write VBA in Excel, there is a free Git extension called Git XL that we maintain which is able to properly Git merge your code directly in Excel: https://github.com/xlwings/git-xl

You can use Pandas via the xlwings package (https://www.xlwings.org)

With a few tricks, you can actually use a professional version control system like Git with Excel, see the slides of my recent webinar: https://www.slideshare.net/xlwings/git-for-excel-files-webin...

You can actually unit test your Spreadsheets surprisingly easily with Python: https://www.slideshare.net/xlwings/automated-testing-of-exce...

Microsoft has been looking into adding Python natively, see: https://news.ycombinator.com/item?id=15927132 but we're still waiting for an official decision...

see also http://docs.xlwings.org/en/stable/rest_api.html for the Python version of the REST api. It doesn't require any VBA...

Our [video course](https://training.zoomeranalytics.com/p/xlwings) allows us to spend more time again on developing xlwings. With regards to your question: Please open a [GitHub issue](https://github.com/ZoomerAnalytics/xlwings/issues) and give us some more background of how exactly you want to use this.

16 seconds demo: https://www.youtube.com/watch?v=KXzG3LBZEWI

Note that Pathio has been relaunched as https://www.xltrail.com - it supports the standard Git workflow and every Git system (GitHub, Bitbucket, Gitlab etc.).

I agree, the issue is not Excel as such but how it's being handled: I once wrote a blog post on how you can unit test Excel spreadsheets, too: https://www.zoomeranalytics.com/blog/unittests-for-microsoft...

It's described in the last paragraph "Behind the scenes"

I wrote a blog post about unit testing Excel workbooks using Python's built-in unittest module: https://www.zoomeranalytics.com/blog/unittests-for-microsoft...

Elegance is always a relative term, but one could argue that having 0 dependencies is more elegant than having 2 dependencies.

interesting! what do you do differently?

Yes...you need Excel installed (on Windows or Mac) as this is a package for interaction/programming with open files, not just reading/writing files.