command names

[alcir]

Let's suppose I'm on a Linux distribution. I already have dcmtk installed (maybe using the distribution package manager). dcmtk already provides commands like findscu, storescu, echoscu and so on. So there is a conflict between dcmtk and pynetdicom packages.

/usr/bin/echoscu
/usr/bin/findscu
/usr/bin/getscu
/usr/bin/movescu
/usr/bin/storescp
/usr/bin/storescu

Is it possible to rename them or the like? Thanks

[mrbean-bremen]

pynetdicom installs Python scripts, not executables, so where is the conflict? They are installed into different locations with different names. Also, you could always create links for convenience.

[alcir]

Yes yes. I.e. pip install installs these scripts (btw aren't scripts executable as well?) in .local/bin. Usually this path takes precedence over /usr/bin, then if I issue echoscu the one installed by pip takes precedence over the one installed by dcmtk via the Linux distribution package manager. Btw, my issue comes from packaging pynetdicom for Fedora Linux. Those script names will be placed in /usr/bin, and this eventually conflicts with the commands provided by dcmtk. I was just wondering if there is a way to avoid that, i.e. by renaming these scripts like i.e. pyechoscu etc.

[mrbean-bremen]

I.e. pip install installs these scripts (btw aren't scripts executable as well?) in .local/bin

Sure, they are also executables. I first thought that you meant an installation time conflict (e.g. overwriting existing ones). Still, the Python scripts have the '.py' extension (while the dcmtk binaries have none), and as far as I understand they would not be called if just using the executable names. What am I missing?

[alcir]

Maybe I'm the one that is missing something. However, as far as I can see, the scripts installed by pip install -U pynetdicom inside ~/.local/bin/ don't have the '.py' extension. So the same happens when packaging pynetdicom (they will be placed in /usr/bin).

[mrbean-bremen]

Sorry, I currently don't have a working Linux system (not counting WSL), so I have to check this later, though @scaramallion may know the answer to this.

[scaramallion]

I think the default (non venv) pip install directory is ~/.local. The only thing I can think of for why they'd end up in ~/local/bin is because they're in the [tool.poetry.scripts] config in pyproject.toml so maybe pip/poetry is using that to decide to put them under bin?

Alternatively, you can use virtual environments to install them where ever you like.

[alcir]

The point is not the path, but the the name of the commands that when packaging pynetdicom will end up in the bin directory (or whatever) and that clash with dcmtk ones. Maybe just adding the '.py' extension to them might solve the issue.

[scaramallion]

I don't think I'll be changing this, sorry.