3 ms·
> With Docker you leverage the existing packaging ecosystem like pip or apt. with import <nixpkgs> {}; runCommand "my-python-package" { buildInputs = [
by chriswarbo 5y ago
> With Docker you leverage the existing packaging ecosystem like pip or apt.
with import <nixpkgs> {};
runCommand "my-python-package" { buildInputs = [ pythonPackages.pip ]; } ''
cd ${/my/project/dir}
pip install
''
- iterati 5y agoThat compared to `RUN pip install <package>` is probably one of the things people are complaining about, no?
- chriswarbo 5y agoI think the complaint is about things like: (import <nixpkgs> {}).pythonPackages.callPackage ({ buildPythonPackage, dep1, dep2, dep3, pip }: buildPythonPackage { pname = "my-package"; version = "123"; propagatedBuildInputs = [ dep1 dep2 dep3 ]; doCheck = true; src = /my/package/dir; }) {} That's how Nixpkgs tends to do things, which has nice features like building each dependency separately, allowing easy overrides, etc. but it requires knowledge of how Nixpkgs orchestrates its Python packages. In contrast, 'runCommand' lets us just run a shell script like 'pip install', which is easier but doesn't have those niceties. Also, depending on the platform, the Nix sandbox may have to be disabled for 'pip install' to work, since Nix tries to prevent network access (I think it's enabled by default on Linux, but not on macOS)