I think @main is a moving ref, but the dependency line in requirements.txt never changes, ...so railway/pip can reuse cached layers or treat it as the same install and skip fetching the latest commit.Can you try pinning the gitHub package to a commit SHA/tag (and updating that SHA on each library release) changes the build input, which kind of forces a fresh install of the new library version.

Thank you for your answer; I considered that option but it seems a bit unreasonable to update the SHA on multiple requirements.txt files (one for each service) every time I update the library (and I’m doing it pretty often). I just want to have Railway rebuild from the library the services with the latest main branch without using the caches. It seems me a reasonable expectation. I cannot understand why I cannot simply disable the caching. A simple solution for a simple problem.

Hi Dharmateja, at the end I did as you suggested, pinning it to the Tag with a Tag deployment script and then propagating it on all the local requirements.txt in the repositories and then pushing them in remote. I would have preferred something faster and more simpler, but it works pretty fine. Thank you again for your advice.