spacekookie has quit [Quit: **aggressive swooshing**]
spacekookie has joined #nixos-dev
Synthetica has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
contrapumpkin has joined #nixos-dev
copumpkin has quit [Ping timeout: 265 seconds]
AlwaysLivid has quit [Ping timeout: 240 seconds]
AlwaysLivid has joined #nixos-dev
evils has joined #nixos-dev
<FRidh>
looking again at https://github.com/NixOS/nixpkgs/pull/102613 I was worried about the performance hit basically reimplementing propagation with nix, however, all the stats go down in value
<{^_^}>
#102613 (by FRidh, 21 weeks ago, open): WIP: Python: wrap and patch using `requiredPythonModules` instead of `propagatedBuildInputs`
<supersandro2000>
python-unstable is the staging for python and eventually merged into staging or staging-next most of the time
<supersandro2000>
but staging or staging-next are not reviewed one by one but only looked for breakages at least that how it look like for me right now
<supersandro2000>
I am just a bit concerned that half of python is broken because something somewhere was overlooked
<supersandro2000>
and if propagatedBuildInputs goes away we need to adjust the reviewing process and for that reviewers need to be aware of that
<supersandro2000>
which should most likely happen in advance
<supersandro2000>
Also do I now need to create a second GitHub account because everyone is blocking me to give important feedback!?
<supersandro2000>
Also I am hearing of that change the first time right now and squeezing it into 21.05 is a bit short planned for my liking
<supersandro2000>
the stdenv.lib removal got planned for 21.11 a couple of months ago which is a simpler to fix breaking eval change
<supersandro2000>
I don't think pythonPackages should receive a bigger rework one month before release especially if not converted packages will fail at runtime. This sounds like we need to do a lot of cleanup and test this properly. The plan for 21.05 was that it will be smoother release than 20.09 was.
<sterni>
this is a feature branch for a WIP PR which has a hydra jobset for testing
<sterni>
I don't think it's time yet to panic about any breakages being rushed in
<supersandro2000>
As far as I know python-unstable is used to mass update python packages and then gets merged into staging which slowly bubbles into master
<sterni>
well python-unstable has hydra-jobset, so it's useful for testing and stabilizing mass changes
<supersandro2000>
or bring in any feedback
<sterni>
doesn't mean that it's a law it's automatically being merged into staging
<supersandro2000>
sterni: then you think it is only in there temporarily for testing?
<sterni>
I'm pretty sure there will be plenty of time to give feedback on the change
<supersandro2000>
Maybe I am just missing information here. Would be nice if such things would be communicated more openly
<sterni>
well there is the wip pr
<sterni>
I mean you can't really inform ppl about much if it isn't ready
<sterni>
from your comments here I get the impression you suspect some kind of ill intent or the plan to rush in changes without them being ready past feedback
<supersandro2000>
well from the branch it looked to me it was ready already
<supersandro2000>
which would be important for me if someone upgrades a python package to a python3 only version which is still required for python2.
<sterni>
“move python 2 only expressions to python2-packages.nix” seems clear enough to me
<supersandro2000>
yeah I think you are right but I would have loved some more communication here especially for reviewers and commiters
<supersandro2000>
also I can't find a section in the python language docs about this
<supersandro2000>
which means I can't point someone to a written guide if they have questions about this. I get asked this a lot and I usually cannot satisfy this question because I don't know the docs well enough to know where to find such information or there is nothing to point to
<lukegb>
from the commit message: "TODO: update documentation"
AlwaysLivid has quit [Remote host closed the connection]
<MichaelRaskin>
supersandro2000: I am pretty sure, given Nixpkgs manual does have some style guide, that there is only Nixpkgs manual and RFCs for any kind of official status
<MichaelRaskin>
Some of the changes you propose lack not just official documentation, but also consensus that they are a good idea
<supersandro2000>
MichaelRaskin: what about nix pills? they should also work
<MichaelRaskin>
For the record: there is no consensus that Flakes as currently implemented, or as documented in RFC, are good enough
<MichaelRaskin>
We have that level of problems with consensus
<MichaelRaskin>
I am pretty sure some parts of Pills are suspected by some to be obsolete
<MichaelRaskin>
Which does not improve my confidense in prescriptive advice there
<supersandro2000>
mmmm. That does not make it easier 😅
<MichaelRaskin>
It kind of does
<symphorien[m]>
the manual still has examples with packageOverrides when it should use overlays
<MichaelRaskin>
There is Nixpkgs manual, and there are accepted RFCs (not many), and that's it
<symphorien[m]>
so even canonical example can be "wrong"
<supersandro2000>
ufff. thats not great.
<supersandro2000>
If we don't have consensus on most things then you will end up with the likings of the reviewer.
<MichaelRaskin>
Which eventually means merging while ignoring a large subset of feedback, yes
<supersandro2000>
as long as I don't propose general bad ideas then I just try to give overall feedback and not care to much about small nouances
<MichaelRaskin>
Yeah, surely there are too few consensus-recognised-bad ideas for you to suggest any
<supersandro2000>
MichaelRaskin: I don't think that is a good idea. Even if we lack official documentation if some idea is not meaningless or bad advice than we should think about it
<supersandro2000>
I think there are enough bad patterns which should be avoided even if they are not document
<supersandro2000>
for example you should use makeFlags instead of calling make manually
<MichaelRaskin>
Also depends
<supersandro2000>
or simple replace patterns should use substituteInPlace rather than a patch
<MichaelRaskin>
Ahhahahaha
<supersandro2000>
well I assume the standard case, not some special exception right now
<MichaelRaskin>
I think by now I have seen all combinations of opinions on that
<MichaelRaskin>
For the record, the easiest to read for me is sed
<supersandro2000>
well, python depedency patching is always done like this because it less likely breaks and is easier to update
<supersandro2000>
sed has the small disadvantage that we can't detect if it does not match
<supersandro2000>
but yeah those are small things which are nice but not required
<supersandro2000>
if someone merges it than the person thinks it is good to merge and can take responsibility for merging it
<MichaelRaskin>
Well, it's true that I usually use sed for things that just plain fail the build if not fixed
<supersandro2000>
thats alright but if the build silently fails than thats not easy to catch necessarily
<supersandro2000>
If I see such things I usually drop a small comment that it could be that but if it is not changed I don't care to much either
AlwaysLivid has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-dev
<MichaelRaskin>
Crazy idea: once level of linebreak-nonagression of nixpkgs-fmt is considered OK, format just the changed lines
<supersandro2000>
hexa-: fyi going to fix home-assistant on staging right now
<hexa->
supersandro2000: where is the breakage?
<hexa->
is it fridhs revert?
<supersandro2000>
python mass update broke at least pandas and ipywidgets
<supersandro2000>
jonringer did a WIP fix PR which I am going to build on
<hexa->
oh, we rely on pandas?
<supersandro2000>
pandas is probably used for some docs somewhere
<hexa->
aye, thanks anyway!"
<supersandro2000>
and it crashes in the tests which I fixed already a couple of days ago but on the wrong branch
<supersandro2000>
I did the PR against master
<supersandro2000>
yeah, I need home-assistant to test the pytest update ;P
<hexa->
such is the python life
AlwaysLivid has joined #nixos-dev
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
risson has quit [Quit: pouet]
tomberek has joined #nixos-dev
ChanServ has quit [shutting down]
Scriptkiddi has quit [Quit: Bridge terminating on SIGTERM]
das_j has quit [Quit: Bridge terminating on SIGTERM]
ajs124 has quit [Quit: Bridge terminating on SIGTERM]
<abathur>
"nixpkgs’ sphinx package is missing certifi as a dependency. Nixpkgs maintainers are often not aware of misisng deps, since some sub dependency has the missing dependency inside checkInputs, making the dependency present for the hydra build. But as soon as doCheck is disabled, those dependencies are missing, and the build fails."
ajs124 has joined #nixos-dev
Scriptkiddi has joined #nixos-dev
ChanServ has joined #nixos-dev
das_j has joined #nixos-dev
das_j has quit [Remote host closed the connection]
ajs124 has quit [Remote host closed the connection]
Scriptkiddi has quit [Remote host closed the connection]
<abathur>
seems like maybe nixpkgs-(hammering|review) or ofborg could be backstopping issues like this by checking for *new* failures caused by setting doCheck or doInstallCheck to false?
<supersandro2000>
this would require to rebuild everything...
<supersandro2000>
at least the package in question and everything if we disable it globally. I think just for the package we could probably hack something together.
AlwaysLivid has quit [Ping timeout: 240 seconds]
__monty__ has quit [Quit: leaving]
jonringer has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
AlwaysLivid has joined #nixos-dev
rajivr has joined #nixos-dev
bpye has quit [Ping timeout: 240 seconds]
bpye has joined #nixos-dev
supersandro2000 has quit [Disconnected by services]