No normal sqa user will have any clue how to do this.
might wanna take this up with the sqlachemy maintainers OR look at sqlachemy tests for how they are testing driver integration.
Some other dialect+driver will do the exact same thing as this jbdc driver.
informix+ifx_jdbc://hostname:port/db_name;INFORMIXSERVER=server_name;delimident=y;user=user;password=pass
becomes
informix+ifx_jdbc://user:pass@hostname:port/db_name?INFORMIXSERVER=server_name&delimident=y
If this is a sqlalchemy engine connect url then it would look like the fixed one.
https://github.com/OpenInformix/IfxPy/blob/master/README.md
This does not appear to support SQLAlchemy. Has a dbapi2 but no official driver+dialect supported by SQLAlchemy.
In which case, why are you bothering? Time would be better spent working on adding SQLAlchemy support than using the dbapi2 directly. In which case the code would be completely non-portable when decide to switch to other driver+dialect
setuptools is for enforcing a cartel, naively can simplify that to for building.
I hope uv completely replaces setuptools and build. Then the maintainers can move on to another racket.
Regular dependencies lack host url and hashes. Those are most important.
For the full details, encourage you to read pep751
^^ look a link! Oh so clickable and tempting. Go ahead. You know that pretty blue font-color is just asking for it. And after clicking the font-color changes colors. Wonder what font-color it’ll become? Hmmmm
i love requirements files, venv, and pyenv.
Bringing requirements into pyproject.toml does not have enough value add to bother with. My requirements files are hierarchical. Extensively using -r and -c options AND venv aware.
pep751 does bring value, by stating both the host url and the hash of every package.
setuptools will fight this to continue their strange hold on Python
wreck 0.3.4.post0 no longer emits build front end options into .lock files wreck#30.
Background of efforts to beg and plead for setuptools maintainers to bend ever so slightly.
Continuing from denied way to pass build front end options thru requirement files so know non-pypi.org hosts setuptools#4928
This hurts those hosting packages locally or remotely on non-pypi.org package index servers. For those who are, the packages themselves give no clue where the dependencies and transitive packages are hosted.
Each and every user would need to have a ~/.pip/pip.conf or pass --extra-index-url pip install cli option. And somehow know all the possible package index servers.
This allows the pypi.org cartel to continue along it’s merry way unimpeded.
Wish pep751 good luck and may there be a .unlock equivalent. Do not yet understand how the pep751 implementers will bypass setuptools and build.
From the hatch docs, not seeing where it discusses publishing to alternative package warehouses.
Does it do away with setuptools? After my experience interacting with the maintainers, now refer to that package as, The Deep State
The Deep State only supports loading dependencies from pypi.org Which has many advantages right up until it doesn’t.
This new standard contains dependency host url. Hope there is a package other than setuptools that supports it.
When bring it up, and prove it, the responses alternate between playing dumb and gaslighting. The truth is The Deep State are gate keepers. And they are in the way.
Training wheels off mode please! So there is support for requirements files that contain on which server dependencies are hosted with more than one choice. Would like the option to host packages locally or remotely using pypiserver or equivalent.
On the positive side, setuptool maintainers did not suggest voodoo dolls, try to wait out the planetary alignment, better economic conditions, or peace on Earth.
That’s how the conversation comes off to my eyes. But form your own opinion. Especially enjoyable for folks who also enjoyed the TV series, The Office.
What are the alternatives to being stonewalled by setuptools?
Disclosure: Wrote requirements rendering package, wreck. I have my own voodoo dolls and plenty of pins
If you encounter any issues or bugs, let me know so I can fix them!
You shoulda lead with that. I love the humor. Can’t stop laughing,
The entire project is a bug LOL!
Start with a pyproject.toml and work from there.
Everything is a bug until it’s got test coverage.
In the .github folder?! That’s gotta be a 1st
Expecting pre-commit as well as isort, flask, black, and mypy
Looked into requirements.txt expecting to find a console UI framework. There is none!
A pattern has emerged that many Python coders have spent not enough to no time learning packaging, dev toolchain, and CI/CD publishing. When asking folks to test your work they’ll be expecting a published package, not a series of amateurish scripts and a bash install script.
Please someone skilled at console UI and packaging please please please help in a paid position.
Can confidently say, you need help.
Not writing more features the OP is good at that. Just packaging and swapping out the prehistoric console UI with a modern console UI framework.
i use
interrogateWhich has a fun bug. Uses ast to compile every module. If a module contains a compile error, get a traceback showing only the one line that contains the issue, but not the module path nor the line #
The only way to find the issue is to just test your code base and ignore interrogate until code base is more mature.
interrogateauthor and maintainers: UX … what’s that?The most obvious bug in the history of bugs … setuptools maintainers,
oh that's a feature request