<eyJhb>
Not apply the patch to that revision? Or patch the patch?
orivej has joined #nixos-dev
<zimbatm>
FRidh: I am looking into maping python packages 1:1:1 mapping between PyPi, attribute and pname
<zimbatm>
would you be open for me to change the organization of the python packages quite drastically?
<zimbatm>
we will need an alias map for the renames at minimum
<zimbatm>
and I was thinking of moving pkgs/top-level/python-packages.nix to pkgs/development/python-modules/default.nix
<zimbatm>
just to co-locate all of that stuff
<FRidh>
zimbatm: attributes should correspond to pypi names. When that isn't the case, its a "bug". pname, ideally as well, but consider that pname is typically inherited by fetchPypi (better to have it the other way around to follow the dependency tree).
<FRidh>
also, regarding the mapping, it is important the names are normalized, so lowercase and with a dash instead of underscore or dot
<zimbatm>
cool, at least we agree on principle
<FRidh>
If you want to make these changes, please open an issue. We then need to find a time to make it because it will conflict with a lot of other open PRs
<zimbatm>
I wrote a script that checks for the mapping right now
<zimbatm>
maybe I can start with posting that report
<FRidh>
Right
<zimbatm>
or do you have one of your own?
<FRidh>
no I don't
<zimbatm>
FRidh: why does the attribure name need to be lowercased?
<zimbatm>
same question about the dashes
<zimbatm>
I understand for example that "." is the package name needs to be replaced with something else
<zimbatm>
isn't that the job of PyPi to enforce that?
<FRidh>
these characters are irrelevant for certain things. However, they are relevant for the name of the files downloaded, which is annoying, because a project can call its project Foo and then an artifact foo
<zimbatm>
for us, I think it's more important to map 1:1 to make packages lookups more predictable
<FRidh>
that's the thing, you cannot
<zimbatm>
as a developer, I often first look things up on PyPi and then want to be able to copy the name into Nix
<zimbatm>
without the 1:1 mapping it means that I have to build and hope that it matches
<FRidh>
which won't work because of the dot as you mentioned. Also, pypi names can start with a number
<FRidh>
you can normalize the pypi name using this simple rule
<FRidh>
only exception is still projects starting with a digit
<V>
nix-repl> { "3" = 4; }
<V>
{ "3" = 4; }
<V>
where's the problem with that
<V>
callPackage?
<zimbatm>
hmm
<zimbatm>
I should have known better for this to be simple
<FRidh>
haha
<FRidh>
so many of these things would have been looking much better if they were simple
<{^_^}>
#102613 (by FRidh, 1 day ago, open): WIP: Python: wrap and patch using `requiredPythonModules` instead of `propagatedBuildInputs`
<FRidh>
I don't want to know how much that is going to break...
<zimbatm>
I started writing a RFC to allow abitrary keys in nix to better support numbered attributes
<FRidh>
V: `let x = {"3foo" = "bar";}; in with x; "3foo" now you need the double quotes, wheres normally with packages we never have to
<FRidh>
though I recall haskell doing it like that, but I may be wrong
<V>
node also does that
<V>
hence I'm not sure that's an issue
<FRidh>
if its consistent, no
<FRidh>
if its some packages, yes
<zimbatm>
the main issue is callPackage and accessing the package with the CLI through `-A`
<V>
yep, callPackage totally breaks
<FRidh>
callPackage as well? did not know that
<V>
well, how do you quote a name in function parameters?
<zimbatm>
`{ 3 }: 3`
<zimbatm>
it would be possible if the Nix language was extended
<FRidh>
right
<V>
it would be possible if we stopped using callPackage :}
<zimbatm>
`{ "3"@alias }: alias`
<FRidh>
but that's a bit out of scope here
<gchristensen>
redefining 3 would be fascinating
<zimbatm>
yeah
<zimbatm>
^ but basically you would have a lookup key, and then have to generate an alias for it
<V>
so, what node has is a let ... in, where all the libraries go in an attrset in the let, and the binaries all refer to that attrset
<V>
I think that's okay
<FRidh>
so you call it also with the set then?
<V>
hmm? the binary packages have `dependencies = [ sources."@angular-devkit/architect-0.10001.7" sources."@angular-devkit/core-10.1.7" ... ];`
<V>
and so on
<FRidh>
yes, and such an expression is then in the form of { sources} : ... ?
<V>
no, it's let sources = { (sources go here) }; in { (programs go here) }
<FRidh>
yes, checking one such file now, its all within the same file
<V>
ofc that could be adapted to multiple files
<zimbatm>
regarding -A, I just tested and `nix-build -A '"3foo.bar"'` works. Where "3foo.bar" is the attribute name
<FRidh>
right. At which point you would use e.g. callPackage and pass in `sources`, so the set
<FRidh>
zimbatm: which requires users to know that they need to use the extra quotes
<zimbatm>
yes but it's possible at least
<FRidh>
but good to know :)
<siraben>
Hi, can anyone help test https://github.com/NixOS/nixpkgs/pull/102766 ? It adds MMIX (yes the CPU in Kunth's The Art of Computer Programming) as a cross compilation target
<{^_^}>
#102766 (by siraben, 1 minute ago, open): Initial implementation of cross-compilation of Knuth's MMIX
<zimbatm>
it's mostly useful for tooling
<zimbatm>
I can see us generating 1:1 maps, and then maintaining the nix aliases as well
<V>
FRidh: to be fair, any user-installed package is somewhat unlikely to start with a number
<V>
indeed, most packages are unlikely to
<zimbatm>
unfortunately somebody decided to name their tool "1password"
<V>
but that's kind of a limitation of Nix :/
<zimbatm>
yeah that's alright
<V>
that is true
<V>
and also 0ad
<V>
and 010 editor
<FRidh>
I think in python-packages.nix we prefix now such packages with `py`
<FRidh>
although, of course, that could lead to a collision
<V>
I would opt to remove such prefixing for consistency
<FRidh>
you need something, because otherwise it means using quotes
<V>
I think that quotes are okay
<zimbatm>
and callPackage is useful
<V>
you could prefix everything with an underscore
<zimbatm>
I'd rather all the dependencies being explicitly named
<V>
like, absolutely everything
<FRidh>
i'd rather python packaging to be sane
<V>
or alternatively, just prefix numbers and underscore-prefixed packages with underscore
<FRidh>
yes, probably the best option
<V>
it's not pretty, but it's also there because we're working around the more fundamental issue of callPackage
<zimbatm>
that's what we do in the top-level
<V>
which itself is poorly-designed
<zimbatm>
but it doesn't work for packages with dots (.) in them
<FRidh>
we do?
<V>
we do?
<V>
I thought 0ad was zeroad
<zimbatm>
_1password
<zimbatm>
_9pfs
<V>
well, that's about as consistent as nixpkgs usually is
<zimbatm>
we have all the data, it's just a matter of enforcing it with CI
rajivr has quit [Quit: Connection closed for inactivity]
jonringer has quit [Remote host closed the connection]
alp has quit [Ping timeout: 272 seconds]
justanotheruser has quit [Ping timeout: 272 seconds]
ris has joined #nixos-dev
ris has quit [Ping timeout: 256 seconds]
saschagrunert has quit [Remote host closed the connection]
ris has joined #nixos-dev
<samueldr>
I think I asked previously, but I'm wondering if, without configuring hooks, it would be worthwhile to allow derivations to opt-out of sandbox paths
<samueldr>
main thing I have in mind is the ambient /bin/sh
<samueldr>
(which on NixOS comes from a specific busybox configuration build)
<samueldr>
while debatable as we could say "it's the posix interface", it _is_ somewhat of an impurity
justanotheruser has joined #nixos-dev
<samueldr>
It feels a bit icky that it's not part of the hashed inputs
v0|d has quit [Read error: Connection reset by peer]
<samueldr>
Disabling all sandbox paths in NixOS makes some things fail, if they were not built beforehand
<gchristensen>
I'm in to it
<LnL>
I would love it if we got rid of that
<gchristensen>
tangentially I bet there is a way to use linker scripts to replace symbolic program paths with materialized paths, and I wish it was a thing
<samueldr>
Would it make sense to have opt-in hashed sandbox exceptions?
<samueldr>
So that /bin/sh in Nixpkgs becomes part of the hash
<samueldr>
But... Backward compatibility
__monty__ has quit [Quit: leaving]
<gchristensen>
it'd be foolish to have my machine connect to machine A for a remote build, and that machine A's nix-daemon connects to machine B to actually do the remote build right?
<samueldr>
why?
<samueldr>
why would you care what the remote builder does?
<gchristensen>
well... sounds fragile :)
<LnL>
I send all my builds through the daemon which is basically the same thing but locally
alp has joined #nixos-dev
zowoq[m] has joined #nixos-dev
luc65r has quit [Quit: WeeChat 2.9]
supersandro2000 has quit [Ping timeout: 265 seconds]