Packaging debian

[cedricboudinet]

• This contribution adheres to CONTRIBUTING.md.

TODO: Check the above box with an 'x' indicating you've read and followed CONTRIBUTING.md.

• [-] I've updated CHANGELOG.md if applicable.

TODO: Check the above box with an 'x' if considered if there were any and then documented client facing changes in CHANGELOG.md. Strike through if this is not a relevant client facing change.

• [-] I've added tests applicable for this pull request

TODO: Check the above box with an 'x' indicating you have considered and added any applicable system or unit tests. Strike through if you considered and decided additional tests were not warranted.

What does this Pull Request accomplish?

Hello.
I added files allowing one to generate a .deb package for installing the library with apt.

Why should this Pull Request be merged?

This PR allows one to install nidaqmx-python without using pip. Maybe NI can add the .deb files to its own apt repository.

What testing has been done?

• I generated the debian package (using debuild -us -uc)
• Then I installed the debian package (using dpkg -i ../path_to.deb)
• I controlled a daqmx card on a freshly install ubuntu 24.04

[cedricboudinet]

In order to build this debian package, python3-hightime debian package should be installed first.
I created another PR, in order to generate it: ni/hightime#54

[zhindes]

What is the benefit of installing a Python package from a distro package manager and not pip?

[cedricboudinet]

The risk with pip is that it may upgrade python packages to newer version that the version in apt. Thus it may break other packages or python based software of the distro. I don't like the idea of having to package managers interfering.

When using apt you know the dependencies will be resolved using the repositories declared in apt (in my case ubuntu and ni).

Allowing user to install via apt doesn't forbid others to install via pip. It's just another feature.

[zhindes]

The risk with pip is that it may upgrade python packages to newer version that the version in apt.

Do you mean pip my upgrade dependencies of nidaqmx-python to versions newer than those dependency versions in apt? Who controls the dependency versions in apt (e.g., python3-tzlocal)?

My biggest concern here is that how do we ensure that any given release of nidaqmx-python uses consistent dependency versions across both pip and apt? I don't want to be in the business of ensuring our codebase supports two differently versioned sets of dependencies.

But... I might not be understanding something correctly.

[bkeryan]

@zhindes Debian no longer allows installing 3rd party dependencies into the system Python. If you try to do this, you get this error: https://stackoverflow.com/questions/75608323/how-do-i-solve-error-externally-managed-environment-every-time-i-use-pip-3

error: externally-managed-environment

× This environment is externally managed
╰─> To install Python packages system-wide, try apt install
    python3-xyz, where xyz is the package you are trying to
    install.

    If you wish to install a non-Debian-packaged Python package,
    create a virtual environment using python3 -m venv path/to/venv.
    Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
    sure you have python3-full installed.

    If you wish to install a non-Debian packaged Python application,
    it may be easiest to use pipx install xyz, which will manage a
    virtual environment for you. Make sure you have pipx installed.

    See /usr/share/doc/python3.11/README.venv for more information.

note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
hint: See PEP 668 for the detailed specification.

Do you mean pip my upgrade dependencies of nidaqmx-python to versions newer than those dependency versions in apt? Who controls the dependency versions in apt (e.g., python3-tzlocal)?

The problem with using pip to install into the system Python is that it doesn't take into account the dependency version constraints of the installed packages. For example, if package A requires tzlocal >=4.0, <5.0 and you install package B that requires tzlocal >=5.0, <6.0, then installing package B may break package A.

NI's recommended solution to this problem has been to use virtual environments and tooling such as Poetry that supports locking dependency versions, but in doing this you lose the convenience of installing into the system Python.

apt installs dependencies and enforces versioning based on the constraints in the .deb packages, so installing package B will either upgrade package A to one that is compatible with tzlocal 5.x or it will produce an error about the version conflict.

My biggest concern here is that how do we ensure that any given release of nidaqmx-python uses consistent dependency versions across both pip and apt? I don't want to be in the business of ensuring our codebase supports two differently versioned sets of dependencies.

We can include version constraints in the control file: https://stackoverflow.com/questions/59249194/debian-packaging-control-file-with-specific-version

[bkeryan]

The nidaqmx package uses deprecation, tzlocal, decouple, and hightime at run time, not only for build/tests. I expect to get ImportError without these installed.

[bkeryan]

It looks like Debian stable still has tzlocal 4.x: https://packages.debian.org/en/bookworm/python3-tzlocal

tzlocal broke compatibility in versions 4.0 and 5.0 ( https://pypi.org/project/tzlocal/ ) and we haven't tested nidaqmx with tzlocal 4.x. Do the nidaqmx tests pass with this version?

[zhindes]

You started a really interesting conversation within NI, and we thank you. At this point, we don't have a strategy here. We think that Linux packages for Python components is important, but we're not certain how we want to execute on that. For now, if you wanted to package this up within Debian (similar to how one of our dependencies, python-tzlocal, is distributed), I don't think there would be a problem with that. I expect that in the future we'll have a coordinated approach for this across all of our Python packages.

For now, we'd prefer not to accept contributions like this until we've figured it out.

[cedricboudinet]

@zhindes
I stated that the package was for debian but it fact I meant Ubuntu since NI daqmx packages are only available for ubuntu.
I do agree with what Brat explained and I find using virtual env very annoying.
It would be good in the future to add system packaging files (for ubuntu and others) in the future to allow one to build their own package if the want to avoid pip.
Bests
Cedric