Private package distribution abomination disadvantages research

[andreir]

Python noob here (BTW is there a dedicated noun for this?)

Intro
I need to store Python packages privately at work. By privately I mean only available inside the company. Because of the infrastructure I am forced to keep .tar.gz packages in an NPM repository. No, at this point I have no ammo to shoot back against this.

This means that the URL to a package is like so: https://some.host.company.com/foo/bar/pa...2.3.tar.gz.

In a Python project in which I want to use the package 'package-name' I create a requirements.txt file with the following content:

--find-links https://some.host.company.com/foo/bar/package-name/-/
package-name==1.2.3

At project build time there would be run the following command:

pip install -r requirements.txt

.. and all is good. The project can be built, run etc. I can also add public Python packages in the requirements.txt file and things still work. I can also add several --find-links lines at the beginning, one for each private package and thing still work.


The problem: I believe this is an abomination which stinks and could create problems later down the road and I would like to learn what are the disadvantages of practicing this. However the internal infrastructure is quite inflexible and it would take a lot of effort to make it to properly internally host and publish packages.

Therefore I need strong arguments against this in order to convince the infrastructure guys. What could those arguments be?
Thank you!

[micseydel]

I've talked about doing at my job exactly what you're talking about doing. What exactly makes it "an abomination" exactly? If it works with pip, I'd expect it to be the right thing.

[andreir]

Thank you for taking time to reply!

The reasons I called it an abomination are a bit more theoretical than practical, indeed:

1. I need to specify the exact URL of the NPM repository directory ("/foo/bar/packaga-name/-/") - yes, there is a segment of a single dash - while using a dedicated (private) Python Package Index would not require this detail, just specifying the index URL once. Therefore for each private package that the project would use I would need to add two lines: one for --find-links to the exact URL and one to effectively refer to the package (see the first code snippet in my first post). Sure, it works, it even allows multiple private package references to live together with multiple public package references but it takes more precision, if the URL varies, it breaks the reference and it takes twice the lines. In a nutshell: works but fugly.

2. The simple idea of using an NPM (Node.js / Javascript) repository for a totally different technology (Python) is a smell in its own

---

So I take it that you also had the challenge of using private Python packages at work and this was the solution that you had in mind?