Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dmt-core: init at 2.1.0 #320189

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

dmt-core: init at 2.1.0 #320189

wants to merge 4 commits into from

Conversation

jasonodoom
Copy link
Member

Description of changes.

Init dmt-core lib.

Things done

  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
    • sandbox = relaxed
    • sandbox = true
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
  • Fits CONTRIBUTING.md.

Add a 👍 reaction to pull requests you find important.

@fsnkty
Copy link
Member

fsnkty commented Jun 17, 2024

Please revisit Contributing to Nixpkgs, and be more mindful of notifying / requesting review from specific users. see the discourse page or matrix channel for requesting reviews.

Copy link
Member

@fsnkty fsnkty left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the use of an overlay, odd formatting and unexplained shell.nix ? would like justification/explanation.

Copy link
Contributor

@NobbZ NobbZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basically what @fsnkty said. Just writing text here to suite GHs requirement to give a reason to "Request Changes".

I will also repeat the review related bullet points here, that I gave you in the discord this morning:

  1. Not like that! Please take a look at the contribution guidelines. (linked by @fsnkty)
  2. Don't use overlays
  3. Don't reimport nixpkgs
  4. Don't provide a shell
  5. prefer pkgs/by-name
  6. unless this is really a python package, then use pythonPackages
  7. remember to add yourself to the maintainers.nix file if you haven't already

I also removed Sandro, as I do not think that they will say anything different in the current state of the PR

@NobbZ NobbZ removed the request for review from SuperSandro2000 June 17, 2024 11:34
Copy link
Member

@eclairevoyant eclairevoyant left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably also want to look at other packages built with python and the nixpkgs manual; if dmt-core is not used for its modules, then buildPythonApplication would be preferable (and note some of the other guidelines mentioned in the manual)

@jasonodoom
Copy link
Member Author

Thanks for the feedback everyone. I will rewrite this. It was my understanding that I needed an overlay but it doesn't seem to be necessary here.

@jasonodoom
Copy link
Member Author

the use of an overlay, odd formatting and unexplained shell.nix ? would like justification/explanation.

The formatting is the result of nixfmt shell.nix should have been omitted. The reason for overlay is because I needed to pull two dependencies which have not been packaged but I realize now this is not necessary and there is an alternative method.

@vigress8 vigress8 self-assigned this Jun 21, 2024
@jasonodoom jasonodoom force-pushed the dmt-core branch 3 times, most recently from bf87ec4 to 5572f2d Compare June 27, 2024 06:26
pkgs/by-name/dm/dmt-core/package.nix Outdated Show resolved Hide resolved
pkgs/by-name/dm/dmt-core/package.nix Outdated Show resolved Hide resolved
pkgs/by-name/dm/dmt-core/package.nix Outdated Show resolved Hide resolved
{ lib, buildPythonApplication, fetchurl, fetchPypi, pythonPackages }:

let
reprint = buildPythonApplication rec {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this a python module? and in any case, why not package it separately?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is. Which is why my initial commit was an overlay. It's used as a dependency. I don't see it as necessary for the time being.

Copy link
Member

@eclairevoyant eclairevoyant Jun 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never said anything about an overlay, overlays are for when you can't just modify nixpkgs itself - but we are in the nixpkgs repo, we can modify nixpkgs itself.

I'm saying these are probably best packaged in separate files.

And as they are modules, not applications, we'd not use pkgs/by-name for those, nor buildPythonApplication.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm receiving conflicting feedback in that case because my initial PR didn't use pkgs/by-name. The description even notes that it's a lib. I'm not sure if anyone is reading it. I'll make those modifications.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no conflicting feedback here. Nobbz said

prefer pkgs/by-name
unless this is really a python package, then use pythonPackages

The phrasing to use pythonPackages was incorrect, it should've been python3Packages. Other than that, we are in agreement; if it's used for its modules, as I said earlier, then it stays in python-modules. If it's simply a binary, then it goes in pkgs/by-name.

So you need dmt-core in pkgs/by-name using buildPythonApplication, while reprint and verilogae go in python-modules using buildPythonPackage, if I understood the purpose of these packages correctly.

Copy link
Contributor

@NobbZ NobbZ Jun 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The phrasing to use pythonPackages was incorrect, it should've been python3Packages

Yeah, my fault, pythonPackages belong in python2-modules and python3Packages in python-modules, I hate whoever came up with that…

Though in general I used "pythonPackages" as the generic name for "the relevant pythonXPackages"

pkgs/by-name/dm/dmt-core/package.nix Outdated Show resolved Hide resolved
pkgs/by-name/dm/dmt-core/package.nix Show resolved Hide resolved
reprint = buildPythonApplication rec {
pname = "reprint";
version = "0.6.0";
src = fetchurl {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prefer fetchPypi, and use hash instead of sha256

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've had trouble using fetchPypi It's what I used earlier but lots of 404 despite following the recommendations in the documentation. Also, DMT_core is the package name as formatted in PyPi. dmt-core will fail.

pkgs/by-name/dm/dmt-core/package.nix Outdated Show resolved Hide resolved
pkgs/by-name/dm/dmt-core/package.nix Outdated Show resolved Hide resolved
pkgs/by-name/dm/dmt-core/package.nix Outdated Show resolved Hide resolved
verilogae = buildPythonApplication rec {
pname = "verilogae";
version = "1.0.0";
src = fetchurl {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as reprint

@vigress8
Copy link
Contributor

Did you try building this on your own machine before pushing? Because it fails for at least two immediate reasons - buildPythonApplication is not at the top-level, and pythonPackages uses python2 which is marked as insecure

@jasonodoom
Copy link
Member Author

Did you try building this on your own machine before pushing? Because it fails for at least two immediate reasons - buildPythonApplication is not at the top-level, and pythonPackages uses python2 which is marked as insecure

Yes I was able to build without issues. Good to know pythonPackages uses python2. Nobbz told me to use that. Hence, why I made the modification. But I wasn't aware of that detail until now.

@eclairevoyant
Copy link
Member

eclairevoyant commented Jun 27, 2024

What exact command did you use to test building?
nix-build -A dmt-core wouldn't work as-is.

@jasonodoom
Copy link
Member Author

What exact command did you use to test building?

nix-build -A dmt-core wouldn't work as-is.

nix-build -E 'with import <nixpkgs> {}; pkgs.python3Packages.callPackage ./package.nix {}'

@eclairevoyant
Copy link
Member

What exact command did you use to test building?
nix-build -A dmt-core wouldn't work as-is.

nix-build -E 'with import <nixpkgs> {}; pkgs.python3Packages.callPackage ./package.nix {}'

Don't callPackage it manually, the whole point of having nixpkgs is that people don't have to run that themselves. Please use the command I provided.

@eclairevoyant
Copy link
Member

eclairevoyant commented Jun 27, 2024

Standalone packages are built using pkgs.callPackage. Use that for testing

No, pkgs/by-name already handles callPackage-ing, and outside of that, the callPackage-ing is done in the appropriate pkgs/top-level/*.nix files. We really need to just stick to using nix-build -A <attribute> here.

Also, I'd appreciate not providing misleading and duplicate feedback on the PR, as this will cause more confusion and frustration.

Co-authored-by: V. <[email protected]>
Co-authored-by: éclairevoyant <[email protected]>
Copy link
Contributor

@NobbZ NobbZ left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Formalizing my response from the discord PR thread:

  1. Please extract the dependencies into their own (python) packages
  2. Please make sure you are following the contribution guideline, especially the part about how commits should be seperated and named. Squash and force push to fix that.

@NobbZ
Copy link
Contributor

NobbZ commented Jun 29, 2024

And… It just happened that I looked at the upstream repo, to figure out what the main scripts name was, also built and tried to check the build output…

There doesn't seem to be any mention of a runnable program in the repo, nor is one in the build output.

This seem to be a library not an application, please package this as a python module, not at the top-level!

@jasonodoom
Copy link
Member Author

And… It just happened that I looked at the upstream repo, to figure out what the main scripts name was, also built and tried to check the build output…

There doesn't seem to be any mention of a runnable program in the repo, nor is one in the build output.

This seem to be a library not an application, please package this as a python module, not at the top-level!

Yes, this is a library. That's why I was confused about the request to move it under by-name/ It's in the description. 😭

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants