New package: DAQmx v0.1.0

[JuliaRegistrator]

• Registering package: DAQmx
• Repository: https://github.com/LidkeLab/DAQmx.jl
• Created by: @kalidke
• Version: v0.1.0
• Commit: 039003306bf34047678e9dc229b6dc035c880fe6
• Reviewed by: @kalidke
• Reference: Register v0.1.0 LidkeLab/DAQmx.jl#2 (comment)
• Description: Julia package: DAQmx

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines are all met! ✅

Your new package registration met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

3. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[kalidke]

[noblock]

Requesting manual merge.

DAQmx is intentionally named after the NI-DAQmx driver API that this package wraps. NI-DAQmx is National Instruments' data acquisition driver, and "DAQmx" is the standard abbreviation used in their documentation, C API function names (e.g., DAQmxCreateTask, DAQmxStartTask), and the broader NI ecosystem.

This is distinct from DAQP (flagged as similar), which appears to be a quadratic programming solver - a completely different domain.

The package provides Julia bindings for NI-DAQmx hardware control, so the name accurately reflects its purpose and aligns with established NI terminology.

[goerz]

The name similarity is a false positive, but the existing package NIDAQ.jl found in #147226 seems like more of a problem. How does this package differ from NIDAQ, and could any new features be contributed to the existing package instead of registering a new one? Seems like @bjarthur did most of the implementation of NIDAQ, so his input on this might be useful

[kalidke]

[noblock]

We submitted PR #37 to NIDAQ.jl in January 2025 to add NIDAQmx 23.5.0 support. After addressing the requested changes, the PR has remained open for nearly a year.

DAQmx.jl is a fresh implementation with a different architecture:

• Parametric task types (Task{K}) for type-safe dispatch
• Auto-generated bindings via Clang.jl for easier maintenance across driver versions
• Julia enums instead of raw constants

We're happy to collaborate with @bjarthur if there's interest in consolidating efforts, but given the maintenance challenges with NIDAQ.jl, we believe DAQmx.jl offers a more sustainable path forward.

[goerz]

Maybe we can convince @bjarthur to add you as a co-maintainer of the package? As a community, we generally strive to make sure registered packages are well-maintained. If the original package is no longer maintained, and the new package addresses all its use cases, it could even serve as a replacement (breaking release). On the other hand, if @bjarthur isn’t on board with the new architecture, having a new package should be fine. I’m not super enthusiastic about the package names being more or less exchangeable, but maybe this is niche enough to be okay

[bjarthur]

i don't use NIDAQ hardware much anymore, but i do still reply to issues and PRs to NIDAQ.jl. not that there are that many. it does though have 49 github stars now and climbing.

the referenced PR to NIDAQ.jl was appreciated in that it upgraded the drivers to the most recent version. but it introduced a change in the API that i felt would be better in a separate PR so that we could discuss independently. there was also a section i felt could be rewritten to be more julian. it changed the error handling in a way i didn't understand. and made some superfluous changes to the code.

for none of these comments of mine did i receive a reply. so no, all the requested changes were not made. i've been waiting for a year for them to respond.

pushing PRs to upstream packages is a huge headache. i totally feel the pain and can personally empathize with the bikeshedding. but each PR really really needs to just one thing, and not touch code that is not related. that's the lesson here.

i think given the still small size of the julia community it is very important to not splinter the package ecosystem. so given that i have no vested interest anymore in this space, i'm happy to add @kalidke as a co-maintainer. alternatively, is there a github organization we could transfer it to?

[goerz]

each PR really really needs to just one thing

That seems like a very reasonable request

i think given the still small size of the julia community it is very important to not splinter the package ecosystem

I agree, and that was very much my concern about this registration

i'm happy to add @kalidke as a co-maintainer

Wonderful!

alternatively, is there a github organization we could transfer it to?

Whenever there's a "generational handover" of a package, having the package in an org is strongly recommended, as that makes it easy to switch out "owners"/maintainers. In this case, NIDAQ is already in @JaneliaSciComp, so that's good. If it would be inappropriate to add @kalidke to that org (because it's only for people directly associated with the Janelia campus), then it would probably be best to move to a separate organization. This isn't my field, so I don't know if a suitable one exists already (you could ask in some appropriate channel on the Julia Slack, including #community). If there is no existing suitable org, then @bjarthur could simply create a new one, like JuliaNIDAQ. Changing the org of an existing registered package requires a manual PR to the registry to update the URLs, though. If that's too much of a headache, adding @kalide directly the repo as an external collaborator, but with sufficient permissions to make releases etc. should also be possible (at least I hope that the repo settings GitHub allow for that)