build: editable dependencies in Python breaks build command

[sthulb]

Currently, sam build uses a requirements.txt file to install dependancies, if a dep is marked as editable (-e in the file), it causes the build command to break with: OSError: [Errno 30] Read-only file system: '/tmp/samcli/source/src'

This could potentially causes issues in a number of situations, most notably, people who use the same requirements.txt file for development and for build.

Ideally, sam build would strip/sanitise the requirements.txt to remove any flags for the build command.

---

SAM CLI Version: 0.8.0

[brysontyrrell]

I ran into this today too.

[kornicameister]

Ditto. I ran into this when building from a privately hosted repository.

-e "git+https://kornicameister:[email protected]/uberrepo.git@master#eqq=uberlib&subdirectory=pkgs/uberlib`

so uber-sad :(

---

sam --version: SAM CLI, version 1.0.0

[cdaniluk]

This has been sitting open for close to 2 years..

[kornicameister]

Yeah...time to invest some time and fix? :D

[irineul]

That's critical! How to work around it?

[kornicameister]

I'd say that one approach to deal with that could be putting something you -e in requirements into separate layer. End result, in lambda runtime, is actually indistinguishable from a requirements file that says -e.

PS. IMHO because I haven't tested that. It just seems reasonable to assume that. PS2. -e can still be used in another requirements file like test-requirements.txt or dev-requirements.txt used solely in development but not when sam build rolls over the project.

[obi-t4]

This might be the workaround: https://stackoverflow.com/a/63668855

[yucer]

PS2. -e can still be used in another requirements file like test-requirements.txt or dev-requirements.txt used solely in development but not when sam build rolls over the project.

I would like to point out another possible scenario that could result into non-production dependencies being used into requirements.txt with one editable version. And it is related to the time gap into the project release and those of its dependencies and how they influences "emergency deployments".

For example:

The project upgraded the whole set of dependencies, but one of them comes with a recently discovered error in the context of your system. At this point it might be that you can not downgrade a version because your database or other set of dependencies was already upgraded. Given that is already being used in prod, you need to take more actions after reporting the issue because your system needs to keep going. If the dependency project is slow to fix regressions:

• make one emergency fork of the deployed version perform there the necessary fixes
• deploy the patched dependency from your forked repository.
• Once the upstream project fixed issue, you deploy upstream version from the original repository again.

It is advisable to do that, just in case that you have knowledge of over the dependency project (for example, you belong to its development community).

Interesting from this case... is that the repository might even public, so it doesn't need credentials... but you would still get the error:

`OSError: [Errno 30] Read-only file system: '/tmp/samcli/source/src'

The error is related more to the editable nature of the dependency deployment than to the private nature of the repository. What I mean is that somehow this discussion has been deviated from the former to the later.

The original problem was not related to specify the credentials of the private repository, it was related to the read-only nature of the path were the editable dependency is going to be installed to. It can also happen in public code that doesn't need authentication.

Am I missing something ? Or still more work is needed here ?