csingley / ibflex

Python parser for Interactive Brokers Flex XML statements
MIT License
85 stars 42 forks source link

Update version in pypi #73

Open eyalk11 opened 1 year ago

eyalk11 commented 1 year ago

Hi,

I see a lot of changes have been made since the last release in 2021. My app depends on the old version in pypi (A pypi package must have dependencies in pypi).

So I suggest to update version and upload it to pypi.

Thanks!

csingley commented 1 year ago

I'm not averse, but I have just run through my budget of attention for dealing with PyPI's security uplift (welcome though it is). I bumped the version to 0.16, but you're going to have to wait until I get around to setting up GitHub CI for this project before you'll see it published to PyPI. I've set up GitHub Actions before, and have templates to use, so it's not out of reach; it's just not happening right now.

I'm not sure it's really such a fantastic idea in the first place to depend on some release (i.e. out of date) version of ibflex. This whole project is in the nature of an arms race with IB... their SWEs move fast & break the API without documenting anything; we respond by crowd-sourcing updates to the XML data model. This is one of those projects where you definitely want to always run the bleeding edge... there's no changes to logic, only to data structures, and you want all those you can get as soon as possible.

If any changes are made to the parsing logic, you can bet your ass I will push a very noticeable version bump & publish that broadly. But I don't see much point in incrementing versions every time a user adds a field or a new model (which is what all those changes are that you are asking about).

Are we talking about this? Is there significant value in sourcing this dependency via PyPI instead of getting it straight from the horse's mouth? Not much more than proving that I'm squatting on the name ibflex in PyPI AFAICT, which I guess lends some credibility vs. a zillion potential GitHub forks whose URIs offer no superficial way of distinguishing source from branch.

Do you have to answer to people for whom this kind of thing would matter, so it's a good trade-off to use stale code in exchange for a green checkmark?

If not, may I suggest just changing your requirements.txt file to directly spec the most up-to-date ibflex models? Something like this:

ibflex @ git+https://github.com/csingley/ibflex.git@master
csingley commented 1 year ago

Glad you're finding value in the package though... nice to see it used to build OSS apps; strength to your arm.

csingley commented 1 year ago

I see you have indeed tumbled to the ibflex install happy path:

consider updating ibflex (from git) as the app in pypi is quite old

What I am suggesting is that you just go ahead & do the same thing for your project as a whole. It's very unlikely to bite you... the logic seems working & stable; I'm too busy to work on that if I wanted to; and nobody else is beating down my door with PRs that could introduce bugs. I tried pretty hard to set up the data structures to make them easy to edit by average users, and easy to validate the changes.

If by some chance there is a sudden ferment in development of the ibflex parser, you can be sure it will be accompanied by an equal attention to the test suite.... and more serious efforts to update the package on PyPI.... probably including some flashing red lights in the setup.py for a while.

eyalk11 commented 1 year ago

First, let me say that I appreciate your work , and I am laughing out of sympathy at the arms race. Thanks for the version bump.

Regarding your point, I understand it. I wonder how much it will matter myself. My point is that it seems more reliable and sound to have at least one solid version of the package in pypi. Even if some of it will be someout outdated, hopefully not completely broken within a month .

It seems that it boils down to some technical issue, which I don't fully understand.  I thought to do what you suggested btw (with requirements file), but I use pyproject.toml mainly and it refused to accept any requirement not in pypi. I can try again just with txt file.

For now it seems like I am going to try suggesting users to update and maybe provide a script for it. I do have the advantage of having a setup. I think there is no need to hurry here. If you need help I might be able to help a bit. You can reach me at eyalk5@gmail.com.

csingley commented 1 year ago

What about setup.cfg? Does that take requirements direct from source, or only PyPI?

Not too bad to split some configs out from pyproject.toml to setup.cfg, although that does get you the gas face from fans of Poetry or whatever Armin is fiddling with in the Python packaging space, etc.

csingley commented 1 year ago

Really wish they’d leave an escape hatch in pyproject.toml - I get where they’re coming from, but some of us actually have plausible reasons for opting out of the straitjacket

csingley commented 1 year ago

They’re just gonna create incentives to stay old & busted if they make it too heavyweight to onboard to the new hotness.

I’ll try to find some time to set up CI here