Hey, any Python experts want to help a Python newbie out? I've been hacking for decades, but I can't say I know Python best practices.
I'm working on github.com/Ovid/sqlitch-v2 (porting some Perl code to Python) and while it seems good to me (but very much alpha and a WIP), I don't know what I don't know. If there's anything obvious I've missed or is unpythonic, I would love to know.
GitHub - Ovid/sqlitch-v2: Python implementation of Perl's powerful sqitch database change management system.
Python implementation of Perl's powerful sqitch database change management system. - Ovid/sqlitch-v2GitHub
Glyph
in reply to Curtis "Ovid" Poe (he/him) • • •at first glance,
- 'src' layout is more popular and has a number of advantages (packaging.python.org/en/latest…) so it's a bit gauche to put your packages at repository root
- 'bin/' directory is unnecessary and failure prone; your project.scripts entrypoint should be fine
- you shouldn't need MANIFEST.in any more? Do you need it because of all these nonstandard files you're including?
- I notice you're including 'uat/**.py' but notably you are *not* including it as a package. That's… odd
src layout vs flat layout - Python Packaging User Guide
packaging.python.orgCurtis "Ovid" Poe (he/him)
Unknown parent • • •@glyph That was AMAZING feedback. Thank you. I'll definitely be taking it on board 😀
I really appreciate you taking the time. I have soooo much to learn here.
Curtis "Ovid" Poe (he/him)
Unknown parent • • •Jason Crome
in reply to Curtis "Ovid" Poe (he/him) • • •Curtis "Ovid" Poe (he/him)
in reply to Jason Crome • • •@cromedome Not happy about this, but:
* The company bans Perl in its tech stack.
* If they switch away from their currently broken tooling, they want something they can maintain and extend.
* I'm working with 200+ devs, many of them newer, and they don't want to use CLI tools. It's trivial for me to extend this new tool with a GUI.
I'm not saying these are great reasons, but that's the pushback.
Jason Crome
in reply to Curtis "Ovid" Poe (he/him) • • •Jason Crome
in reply to Curtis "Ovid" Poe (he/him) • • •Curtis "Ovid" Poe (he/him)
in reply to Jason Crome • • •Sam Kington
in reply to Curtis "Ovid" Poe (he/him) • • •@cromedome Out of interest, what sort of GUI do the command-line-adverse want / will they get? A menu item in VSCode or similar? A button in GitHub and/or their CI website? Something else?
I mean, I think far more people should have said “no, I want to use a proper GUI rather than basically CP/M or MS DOS” 20 years ago, rather than people deciding to carry on using dinosaurs like vi or emacs, but I’m concerned about how you automate this stuff.
Curtis "Ovid" Poe (he/him)
in reply to Sam Kington • • •@skington @cromedome There weren't specific, beyond hyperventilating at the thought of the command line.
I could try to duplicate UX of Flyway (red-gate.com/products/flyway/), but at the core level, their database management is so poorly designed that I want to step back and rethink. Will have a play with interfaces later.
Redgate Flyway - Automate database deployments across teams and technologies - Redgate Software
www.red-gate.comGlyph
in reply to Curtis "Ovid" Poe (he/him) • • •Curtis "Ovid" Poe (he/him)
Unknown parent • • •@randomgeek @glyph Looked into ruff, haven't adopted it, though.
And I've applied most of his suggestions to github.com/Ovid/sqlitch-v2
Now working on #mysql support.
GitHub - Ovid/sqlitch-v2: Python implementation of Perl's powerful sqitch database change management system.
GitHubCurtis "Ovid" Poe (he/him)
Unknown parent • • •