vallettea / koala

Transpose your Excel calculations into python for better performances and scaling.
GNU General Public License v3.0
147 stars 59 forks source link

Python 3 - Take 2 #253

Open strichter opened 4 years ago

strichter commented 4 years ago

Cleaned up tox setup from PR #248.

strichter commented 4 years ago

Not sure why Travis is not reporting back, but th ebranch is passing for the latest 2 Python versions: https://travis-ci.org/github/vallettea/koala/builds/681124672

kmonson commented 4 years ago

Thanks for this. I'm not a tox expert so I didn't know where to start.

kmonson commented 4 years ago

I've closed my old pull request (which was the starting point for this one)

Pull in this guy instead.

kmonson commented 4 years ago

What is the holdup on this?

bradbase commented 4 years ago

(Quite obviously) There are very few people maintaining this project.

The organisation who began the project (We Are Ants, Civic Hackers - https://weareants.fr/) have decided it is no longer of interest and have moved the project into ownership of one of their partners. That person has provided collaborator access to a handful of people who were interested in the project at the time. Most of those people have since moved on to other projects. I am one of those aforementioned people (I was here under account Brad-Eki).

I hope @vallettea doesn't mind me going into such detail but there are a number of issues at the core of this project which are difficult to resolve. Not suggesting I am the last word on programming but, at the very least, I have found them exceptionally difficult to resolve. Python 3 support is the tip of the iceberg. For example, the code in the "basic" use case/example works fine, but the "advanced" use case no longer works.

To summarize issue #249; Starting last year and progressing through the beginning of this year I tried for a number of months to clean and tidy up Koala to bring this project to order and I failed (primarily I require the "advanced" features). Eventually I decided a re-write of Koala was faster and easier so I wrote a new library with the intent to get feature parity with Koala and hand the code over. I got close to feature parity and there was no appetite from the Koala project to adopt my re-write so I have since released that code under the project xlcalculator.

strichter (the chap who wrote the PR we are commenting on) is an extraordinary talent and has been an incredible contributor to xlcalculator. Due to his efforts xlcalculator has become production quality. Xlcalculator supports Python 3.

xlcalculator is not syntactically compatible with Koala but is well close enough to being feature compatible.

Please confirm one way or another; If you'd like to ensure the PR we are commenting on gets accepted I'm happy to try and recover my password for the Brad-eki account and see if I still have access enough to approve the PR.

bradbase commented 4 years ago

@kmonson, how are you going with the above?

kmonson commented 3 years ago

@bradbase Sorry I missed your messages.

If there is no one supporting this project anymore then there is no point. I've already got a whole slew of commits after this pull request to add features, support more functions, and fix a few bugs. I was hopping to get those in as well, but with the turn around time for new problems resolutions getting into a release I'd just end up using my fork anyway.

xcalculator looks really promising for us as an alternative. I see from your readme that you've addressed some of my pain points from koala. I was one the verge of rewriting the internals of koala until I saw your project and https://github.com/vinci1it2000/formulas. Unfortunately neither support OFFSET and that is kind of a deal breaker for us. We need just about everything you categorize as "Lookup and reference" in xclaculator because our model relies heavily on table lookups. (Also the NOT function, but that's going to be trivial.)

I'll see if there is anything I can do in my free time to bridge the gap between what xcalculator or formulas provides and what we need to use it. I would really like to switch off of koala for something that is maintained.

bradbase commented 3 years ago

@kmonson Thanks for responding :D

I'm happy to take this offline or over at xlcalculator.

The categories I have used for the Excel functions are the Microsoft categories.

It is true OFFSET is not supported but isn't impossible to do so. I have taken a few months break from xlcalculator and expect that to continue for another few weeks. I expect to be much more available from May. Until then I'm happy to provide light-weight support but am unlikely to be able to code any functions myself until then.

If you'd like pointers on how to implement the functions you are interested in, maybe raise an xlcalculator issue for OFFSET, NOT and the other functions which are deal breakers so we can discuss over there. I'd love for those functions to be implemented because they are so commonly used.

I'd really like to get xlcalculator to a point where adopting it is a no-brainer. Supported functions is obviously one key measure. But I like to think the pedantic nature of replicating the results Excel would produce has some value in this space. Both for the good and the bad. If you go through out tests you'll notice xlcalculator there is an entire suite where we compare the Python function results against results from Excel. No other library does that.

Formulas is really good but it is tuned for engineering solutions and isn't so pedantic on reflecting the way Excel does things.

Pycel is another library that implements OFFSET and NOT. But, again, that library isn't so pedantic on reflecting Excel's results. It is primarily tuned for generating network graphs, originally intended for calculating aerodynamics. Generating the network graph is intrinsically at the center of the library and is the primary concern for the library.

Cheers

kmonson commented 3 years ago

I'll make up some issues for the missing functions over at xcalculator so we can move this discussion over there.

I really appreciate that you're focused on matching Excel's behavior. As well as using our model for calcs we populate the same model with openpyxl and include it in the program outputs so it's important that what our code produces matches Excel. I've created a bunch of internal tests to verify that every time we update our Excel model.

I used pycel for in program previews (before we pursued replacing our hand written python model with Excel) and I haven't gotten around to replacing it with my koala fork. It falls short on supported functions and I found it unsuitable for the modeling task. Also it's not maintained anymore. Part of the reason I picked koala was that at the time I was led to believe it was still actively maintained. I adopted it about 2 week after it went dormant. Bad timing on my part.