Exrension .in confusing

[shurshilov]

Why is the .in extension logically incorrect?

1. The file has not changed its structure. It didn't become yaml or json. A plain text file as .txt
2. Semantics. the purpose of the file is python dependencies, they haven't changed either.
   Therefore, I am 100% convinced that the .in format is an architectural error of the project.

What are the problems:
when developers enter the project, they see a new .in extension and do not understand what to do with it. The project has to be accompanied by additional documentation about the tool

the correct name:
requirements_pip_compile.txt
or
requirements_in.txt

[AndydeCleyre]

You should already be able to name the input and output files whatever you want.

[shurshilov]

You should already be able to name the input and output files whatever you want.

Thanks for the feedback. Yes, but the documentation gives an example with .in it may be worth mentioning this, it's just that many people follow the documentation.
And what is your personal opinion on this?

[AndydeCleyre]

I don't have any strong feelings about it, but I think the current convention is fine enough. Other things that might appeal to me are double extensions, like .txt.in or .in.txt or .locked.txt. Extensions are slightly easier to script around than, say, underscores, since tools and languages often have specific methods to deal with them.

To be clear, I didn't mean to dismiss any of your thoughts, I just wanted to make sure you know you can name the files whatever you want.

[RonnyPfannschmidt]

I believe the practice to add. In to files that get expanded dates back to at least autotools

There's also manifest.in in setuptools

Its a natural choice for anyone remembering that age

[WhyNotHugo]

A double extension like myfile.txt.in is typically used when the build system performs variable substitution and produces a myfile.txt. That is not the case here. Using that would only add more confusion.

[webknjaz]

I don't think that it's reasonable to change the default. It's been like this for ages and would break existing users' expectations. It is used widely and integrated on scale in many systems. For example, Dependabot recognizes pairs of .in and .txt files with the same base name as managed by pip-tools and calls it properly.
Updating the UX would require a multi-year depreciation effort and there's nobody around to take on such a long-term project. Besides, as others have pointed, people can opt to use whatever filenames they like. And many have: for example, coveragepy uses a .pip extension.
Personally, I think it's a good idea that there's a commonly known pattern for declaring direct deps vs. constraints with transitive deps.

[shurshilov]

I found two more problems besides the above two:
OLD points
1.The file has not changed its structure. It didn't become yaml or json. A plain text file as .txt
2.Semantics. the purpose of the file is python dependencies, they haven't changed either.
Therefore, I am 100% convinced that the .in format is an architectural error of the project.
NEW points:
3.vscode does not recognize the .in extension as python requiremetns, so when you point at a package with a version, a tooltip does not pop up with a link to the pypi location of the package.
4. Windows does not open this file by default in vscode, it also considers it an unknown extension and opens it in notepad by default.

[WhyNotHugo]

1.The file has not changed its structure. It didn't become yaml or json. A plain text file as .txt
2.Semantics. the purpose of the file is python dependencies, they haven't changed either.

These are factual statement which are true. Where is the problem?

3.vscode does not recognize the .in extension as python requiremetns, so when you point at a package with a version, a tooltip does not pop up with a link to the pypi location of the package.

This sounds like an issue in vscode. Can you report it there? A code editor should be able to recognise file syntax regardless of file extension.

[WhyNotHugo]

Updating the UX would require a multi-year depreciation effort and there's nobody around to take on such a long-term project.

And it would most likely be pointless; by the time the multi-year process is done, I'd expect the new python lock file to be far more widespread.

[webknjaz]

Updating the UX would require a multi-year depreciation effort and there's nobody around to take on such a long-term project.

And it would most likely be pointless; by the time the multi-year process is done, I'd expect the new python lock file to be far more widespread.

Exactly! Also, with pip lock being a thing now, we need to rethink our approach towards PEP 751 anyway.

It's likely that some documentation might be useful, though. I keep seeing people confusing the semantics of "python deps" vs. "project deps" vs. "lib deps" vs. "app deps" vs. "venv deps" vs. "constraints".

I think we should be more clear that .in are for abstract direct deps and .txt are constraints for concrete+transitive pins: #2051.

[sirosen]

This issue is not providing sufficiently strong rationale to change a decision from ~10 years ago.

requirements.in/reqs.in is so strongly established that I've seen these filenames used in discussions in the Packaging section of DPO as a shorthand way of referring to "abstract requirements". If some other toolchain does not support this file naming convention, then either

a) you should treat that as a defect in that toolchain

or

b) you should use your own judgement and use filenames of your own choosing, like requirements-in.txt, etc.

---

Maybe the choice of filename is regrettable (I do not really think so), but given the ecosystem role of pip-tools and age of the decision, we'd need a good reason to change it. And at a minimum we'd need maintainer consensus that the change is a good one, which seems unlikely.

I'd be happy to author or review documentation improvements if there are implementable suggestions, but unless there's a significant breaking development in this thread, I intend to close it after a couple of weeks as a wontfix.

[webknjaz]

@sirosen I've been meaning to close this too. Just thought that if the actionable thing is adding some docs, maybe this should be done with the issue still open. But regardless, feel free to close it if you intend to track possible docs improvements in some other way.