Migrate python packages from nose to pynose #311054
Comments
mweinelt
changed the title
fixes build on python3.12 part of NixOS#311054 Signed-off-by: Florian Brandes <[email protected]>
fixes build on python3.12 part of NixOS#311054 Signed-off-by: Florian Brandes <[email protected]>
|
In mdmintz/pynose#16 and mdmintz/pynose#26 it was revealed that |
|
Given that pynose is illegal, copyright-violating software, which by virtue of violating the GPL has lost its right to use the software under the terms of the GPL, it's not remotely clear to me that NixOS is legally allowed to redistribute the tainted edition of the software at all. I guess I'm not really surprised that some people automatically assume they can do so regardless. |
|
I'm working on a treewide removal of pynose. |
I'm not familiar with nose/pynose, but I'm wondering if something like |
That. |
|
Nonfree typically means the upstream project legally has the right to be the upstream project, they simply choose to only grant you the ability to use that code under a non OSI approved license. Where does the concept of a "disputed" license value come from? Under what terms and conditions could or would a user install such a thing, even as a leaf package? |
That sounds reasonable in the context of natural languages. In the context of the metadata that comes with derivations, it's just a single boolean which an individual maintainer could set for whatever reasons... the minimal semantics I could infer from it is "not to be redistributed by Hydra" and "just because you can build it doesn't mean anyone's allowed you to use or distribute it"
On terms of taking their own risk; I wouldn't mind |
|
The upstream has no right to redistribute the code under the given license. That is the issue we run into. |
In the context of naturally attempting to convey useful and usable semantic meaning for conventional language concepts, it sounds reasonable to say "if an individual maintainer sets a deceptive value that deceives the user into associating the meaning with that of projects which are under proprietary, but entirely legal, licenses -- the individual maintainer is acting against the best interests of the project and shall receive an infraction by whichever disciplinary measure the distribution in question uses to penalize bad behavior". I don't quite see the purpose in defending the notion of packaging illegal software using language intended to seem similar to commercial+proprietary redistributables. Is this a thought experiment or a practical desire? |
|
Sorry @eli-schwartz, I hadn't read the entirety of 16 and 26 when I first commented, and now, maybe as a result, we're mixing a discussion about implementation details and one about policies.
Semi-practical. We've several expressions that describe how to build certain pieces of "legal" software for which, however, we do not have (but the user might) a legal way of obtaining the sources or for which we wouldn't have the right to distribute the results. This is not quite the same as the present situation, but bear with me. These expressions would reference a generally unavailable source, but (a) we wouldn't build them in the CI (ergo never access the source nor distribute), (b) we'd mark them so that they don't evaluate before the user explicitly opts in. On the implementation side, and I don't particularly like that we confound the names, the latter is practically done by resetting While this error message would be wrong of course (maybe now's a good time to reword it), since there's no, as such, a license granting anything to anyone, the way I read it it does attempt to communicate that "whatever the licensing situation is, you're not automatically permitted to do anything with this software and it's your task to find out the terms and get the consents". Essentially, when I set the license value, I treat The licensing information in the The policy question of when it's worthwhile or acceptable to provide expressions for software which we can't reference a "legally available" source for (proprietary, unlicensed, ...), and whether in particular it's acceptable to reference sources we do know to violate other authors' dissent is global. While this might be worth answering globally "once and for all", we already have, by the previous paragraph, enough local information to remove the package... EDIT: I seem to have deviated from the original point here. Back to "a thought experiment or a practical desire". Representing correct knowledge about upstream projects definitely is a goal. The present issue is an edge case where our tooling ( |
|
Interesting implementation details! In gentoo, there is a global repository directory containing license terms and conditions, and the file
Users would have to specify which licenses they accept to use (the default is Project policy is to "ask the opinion of others before committing a new license, if you're not sure about the license". This is somewhat flexible obviously. The addition of new licenses is, incidentally, easy to coordinate and watch for changes. :D Getting the license wrong is a very human mistake, adding something that isn't a license at all would probably raise a few eyebrows. There's no real room to mark a package as nonfree without stating the specific reason it isn't free, since "unknown" licenses are banned by CI-enforced policy. The license groups in particular are very neat. It encourages accurate specification of "terms and conditions" independent of "is this license one that I consider free", since you can have arbitrarily grouped or recursively-grouped license sets to describe policy with, instead. |
|
Ah, w.r.t. the edit: one could |
|
Nixpkgs is orderly enough about "free and opensource" licenses (there's a list maintained in a single place which other expressions reference, e.g. As for NVidia, one approach usable today could look something like this: nixpkgs/pkgs/top-level/release-cuda.nix Lines 17 to 28 in 7a95a89 |
part of NixOS#311054 Signed-off-by: Florian Brandes <[email protected]>
part of #311054 Signed-off-by: Florian Brandes <[email protected]> (cherry picked from commit 30a05b5)
|
Spiritual successor: #326513 |
|
This should hopefully help clear up any confusion: mdmintz/pynose#36 |
The
nosetest runner will never run on Python 3.12, and we're replacing it withpynoseinstead. On top of that, packages relying on nose have largely been unmaintained and might be dead leafs or using another test framework entirely. It is also to be expected that they need to be converted to the PEP517 builder in the process of fixing them.The following packages are in the
python3Packagesscope and should be addressed first. The final goal is the removal ofnoseand related packages.python311Packages.{cov-core,nose-cov,dyn,pylti}: drop #313182python312Packages.dyn: refactor #313476The text was updated successfully, but these errors were encountered: