overview for logging

nightfullstar/willyoumarryme_bot_telegram by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 2 points 1 week ago* (last edited 1 week ago)

Yeah saw that. It's awesome you are responsive. Gave the project a star cuz it deserves it!

Sent two other issues your way. One just a file rename. The other specifying authors contact info.

nightfullstar/willyoumarryme_bot_telegram by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 3 points 1 week ago

Should add this as an issue

This could lead to the girl having a legitimate reason for declining a marriage proposal from a TG bot

nightfullstar/willyoumarryme_bot_telegram by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 4 points 1 week ago

Oh look!

This noob doesn't know how to setup a TG bot. What a poser

Oh wait! That's me

willyoumarryme_bot_telegram#1

nightfullstar/willyoumarryme_bot_telegram by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 3 points 1 week ago

two words

plausible deniability

If a couple can get married on the blockchain, mistakenly accepting a proposal from a bot is not far ... oh that just happened!

constraint vs requirement. What's the difference? by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 2 points 3 weeks ago

Woah! Was giving the benefit of the doubt. You blow my mind.

The locking is very very specific to apps and dev environment.

But lacking constraints is like cutting off an arm.

constraint vs requirement. What's the difference? by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 2 points 3 weeks ago* (last edited 3 weeks ago)

my position is it's not messy enough

Lets start off by admitting what the goal is.

We all want to avoid dependency hell.

Our primary interest is not merely cleaning up the mess of requirements files.

Cleaning up the mess results in some unintended consequences:

noise
complexity
confusion

noise

All the requirements information is in one place. Sounds great until want to tackle and document very specific issues.

Like when Sphinx dropped support for py39, myst-parser restricted the Sphinx upper bound version, fixed it in a commit, but did not create a release.

Or cffi, every single commit just blows our mind. Adding support for things we all want. So want to set a lower bound cffi version.

My point being, these are all specific issues and should be dealt with separately. And when it's no longer relevant, know exactly what to remove. Zero noise.

complexity

When things go horribly wrong, the wrapper gets in the way. So now have to deal with both the wrapper and the issue. So there is both a learning curve, an API interface, and increased required know how.

The simple answer here is, do not do that.

confusion

When a dependency hell issue arises, have to deal with that and find ourselves drawn to poetry or uv documentation. The issue has nothing to do with either. But we are looking towards them to see how others solve it, in the poetry or uv way.

The only know-how that should be needed is whats in the pip docs.

Whats ur suggestion?

Would prefer to deal with dependency hell before it happens. To do this, the requirements files are broken up, so they are easier to deal with.

Centralizing everything into pyproject.toml does the opposite.

Rather than dealing with the issue beforehand, get to deal with it good and hard afterwards.

11

constraint vs requirement. What's the difference? (programming.dev)

submitted 3 weeks ago* (last edited 3 weeks ago) by logging_strict@programming.dev to c/python@programming.dev

27 comments fedilink

In a requirements-*.in file, at the top of the file, are lines with -c and -r flags followed by a requirements-*.in file. Uses relative paths (ignoring URLs).

Say have docs/requirements-pip-tools.in

-r ../requirements/requirements-prod.in
-c ../requirements/requirements-pins-base.in
-c ../requirements/requirements-pins-cffi.in

...

The intent is compiling this would produce docs/requirements-pip-tool.txt

But there is confusion as to which flag to use. It's non-obvious.

constraint

Subset of requirements features. Intended to restrict package versions. Does not necessarily (might not) install the package!

Does not support:

editable mode (-e)
extras (e.g. coverage[toml])

Personal preference

always organize requirements files in folder(s)
don't prefix requirements files with requirements-, just doing it here
DRY principle applies; split out constraints which are shared.

Are we PEP 740 yet? 🔏 by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 1 points 3 weeks ago

Betteridge’s law of headlines

nice catch and thanks for the teaching moment

PieFed, a FOSS Feed Aggregator alternative to Lemmy, but faster by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 2 points 3 weeks ago

Admit it, the author brought a smile to your face!

Can't stop laughing, the codebase and authors stance on packaging are hilarious.

After reviewing the source code, was gonna write helpful feedback. Then realized this project is perfect as-is.

A perfect example of what a python project looks like by those who really really hate packaging and UX.

Once upon a time, I was that guy too

PieFed, a FOSS Feed Aggregator alternative to Lemmy, but faster by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 2 points 3 weeks ago

Rally to protect the acolytes from those demanding efforts towards packaging and common practices!

Hey it works on their machine and maybe will on yours

Unless you use Void (sv) or Alpine Linux (openrc). Those people suck the fun out of the room.

Everyone should be using systemd, expect Grandma. She gets a smartphone.

Recommended way to run my scripts from a venv? by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 1 points 1 month ago

thanks for the head up on nox. Syntax seems like a tox meets pytest.

Recommended way to run my scripts from a venv? by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 1 points 5 months ago

Just activate the venv and then put it out of your mind. Can activate it with either a relative or absolute path. Doesn't matter which

LPython 0.21 Released For Alpha-Stage Python AOT Compiler by logging_strict in c/python@programming.dev

[-] logging_strict@programming.dev 1 points 7 months ago

LPython will be obsoleted by Mojo