No. When such upper bounds are respected, they contaminate other packages, because you have to add them yourself to be compatible with your dependencies. Then your dependents must add them too, etc. This brings only pain. Python 4 is not even a thing, core developers say there won't ever be a Python 4.h
> you have to add them yourself to be compatible with your dependencies
This is no more true for version upper bounds than it is for version lower bounds, assuming that package installers ensure all package version constraints are satisfied.
I presume you think version lower bounds should still be honoured?
The point is that you can know that a lower bound is necessary at the time of publication; an upper bound is either speculative or purely defensive, and has possibly unnecessary consequences for your dependents.
You can also know that an upper bound is necessary at the time of publication -- for example, if your foo project uses bar 2.0, and bar 3.0 has already come out, and you have tried it and found it incompatible.
In the reverse direction, many version lower bounds are also "purely defensive" -- arising from nothing more than the version of the dep that you happened to get when you started the project. (Just because you installed "the latest baz" and got version 2.3.4, without testing there is nothing to say that version 2.3.3 would also work fine, so adding the version lower bound >=2.3.4 is purely defensive).
A friend shared his technique with me, and after adapting it to my needs, it works well. None of the other commonly mentioned techniques ever worked for me, because they ask for focus, which is the opposite of what my brain needs to fall asleep.
Here's his technique: pick a letter of the alphabet, and find as much words that start with this letter as you can. Once you can't find words anymore, pick the next letter. Doesn't work for me, my brain won't ever stop.
I noticed I have to visualize stuff in my head to fall asleep so my adaptation is to pick a single letter and a single word, and visualize it in my head, using it, manipulating it, experiencing it, whatever. For example: letter P, word Pineapple, imagine you're holding a pineapple, you feel the roughness of it's skin in your hands, you throw it in the air and catch it again, you take a knife and slice it on a wooden table on the beach, etc.. The dream kicks in seconds. Without external interruptions, after a few minutes I'm asleep (instead of rummaging for hours).
If you notice you're stuck in a loop/pattern (for me anything about text, like reading or writing, and voice, like listening and speaking, or stressful scenarios), just pick a new letter, pick a new word, visualize it.
I pick a category, like fruits and vegetables or cars, and then try to come up with a word in that category that starts with every letter of the alphabet in order. To keep it relaxing I synchronize it with my breath. On the breath in, I note the letter I am on: "C" for example. On the breath out I note the word: "Cantaloupe". If I don't have a word for that letter by the time I breath out, no big deal, I conceptualize whatever was in my mind at that point and then repeat the letter on the next breath in.
Another thing I do that works well for me is just counting breaths. On the breath in I think "in-n-n-n-n" and on the breath out I count. When I lose count, and I am still awake, I start again from 0, as any sane programmer would ;-).
ETA: For a couple of months I have been doing a short gratitude routine as I am getting into bed. I acknowledge the good and positive things that happened during the day, and I tell myself that I did a good job (if I did) or that I did as well as I could today and that's good enough for today. Then I think, "And now it's time for rest. I've been looking forward to this." If any part of me starts thinking about the day again or thinks about tomorrow, I gently reassure it that I will attend to all of this tomorrow morning and that now it's quiet time and time to rest.
All of this plus 250 mg of magnesium an hour before bed has made falling asleep super consistent and easy.
I do something similar. If I'm not anxious but awake, I try to just visualise random stuff, random worlds. Somehow my brain is decent at that and I slowly drift off, though I sometimes get a jolt from reality.
Recently I found that when I'm anxious it's better to try and imagine doing a hobby. I just imagine myself trail running. Reduces anxiety, pushes me towards sleep.
I live at a 36-hours-at-a-time rhythm and it's absolutely brutal seeing as its 5:30am and I should have been in bed a long time ago. Going to give this a go and report back. I did the lucid dream thing for awhile but holding a heavy object in my hand and then dropping it got quite annoying (to train yourself to be more aware of when you enter a hypnagogic state).
I'll get a closer look at the code tomorrow, but maybe you can provide an answer in the meantime: how do you handle line numbers? Bash's LINENO is unreliable, contrary to Zsh's, see https://gist.github.com/pawamoy/cca35f0f5ccd56665d6421e9b2d2.... That's why I eventually gave up writing any profiling/tracing/debugging/coverage tool for Bash and moved to support these in Zsh instead. Unfortunately Zsh is missing a ZSH_XTRACEFD like Bash, but that's another story (never finished contributing one). Here's my own attempt at a shell profiler: https://github.com/shellm-org/profiler :)
the LINENO is (mostly) reliable, so long as the code that is running comes from a file somewhere. timep runs the code that you want profiled by generating a script file that:
1. declares all the variables timep uses to track state and things like that
2. initializes all the extra stuff needed to make the instrumentation work (initial values for some variables, defining instrumented traps, setting `set -T`, etc.)
3. runs the code to be profiled. for scripts the script content is added here. For raw commands the commands are added. For functions the function is defined and then called as a function.
this is saved as a script in the timep tmpdir (by default a unique directory under /dev/shm/.timep), made executable, and then it is run. The setup is done like this for a few reasons, but the biggest of those is "to get correct LINENOs.
This makes it so that LINENO gives a correct result, only it is shifted by however many lines it takes to do steps 1 and 2.so the code records the lineno just before the "code to be profiled" starts running, so it can shift it back the right amount when it records it.
That said, timep has a handful of very minor bugs (4 to be precise) - one of them is that fir functions that call a subshell the lineno is wrong (it is shifted forward by a few hundred lines). So it isnt quite 100% perfect, but is pretty close.
(side note: the other 3 bugs have to do with command grouping in the output being ever so slightly off for deeply nested subshell + background fork sequences).
timep also includes a function that I wrote that tries to get the original function code (instead of the version that `declare -f` outputs), so that the lineno's on functions match up better with the original function definition source code.
I follow a sponsorware strategy: public version with basic features, paid version (monthly subscription) with more features. When a funding goal is reached (dollars per month), a subset of paid features become available to everyone. Paying users essentially fund the development of new features. I don't have any "app", only tools and libraries :)
Following the /llms.txt standard proposition, I create a MkDocs plugin that generates an /llms.txt file at the root of your site. So, same thing, but generates the Markdown document from your docs (possibly containing API reference) instead of your code.
I maintain git-changelog, which is a similar implementation in Python (started two years before git-cliff). When I discovered git-cliff a few months ago, I was very impressed by the number of things they support. Also, being written in Rust, it must be much more performant than my Python implementation (which indeed has trouble with huge Git histories). I have started recommending git-cliff to some of my users who request features I don't yet support :)
Author here (I'm a bit late!): indeed Griffe's goal is to be able to support any Python code, natively or thanks to extensions. Thanks for sharing by the way!
This is probably a bit off-topic, but I wonder if you know about the GenIDA project: https://genida.unistra.fr/. It's basically a research website where families can register and answer questionnaires about the everyday life of patients with rare diseases. The data can then be used to discover new things about these rare diseases. They have a Kleefstra cohort if I recall correctly.
Maybe you could get in touch with the people in charge, like Jean-Louis Mandel.
I'm not sure how much we are in contact with them through idefine. We should definitely encourage patients to signup on genida. This increases awareness at many levels. Thank you. I'll study genida's website.
