Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.


I just found peru and have played with that a little. I would really love to deploy this to our company but I am missing one key feature. We need the ability to lock modules to a specific version (tag preferably) or better, to be able to specify a constrain for version.


    rack_example: rack/  # This is where we want peru to put the module.

git module rack_example:
    url: git://
    version: 1.3

This would fetch only module with version 1.3.*. We need this because our imaginary project is compatible with rack 1.3, not with 1.4 but we still want patches for 1.3. If I peru reup, it downloads the most recent version, which is 1.4.1.

I know I can write my own plugin (and I probably will for tarballs), but I would really like to use builtin plugins so I wouldn’t have to deploy all plugins to all new employees that join our company.

The best option would be to implement something like composer has (and other dependency managers).

Issue Analytics

  • State:open
  • Created 5 years ago
  • Comments:20 (10 by maintainers)

github_iconTop GitHub Comments

oconnor663commented, Jan 24, 2019

I think a good design will be able to support both use cases at the same time. On the one hand you have projects that commit their rev fields. There, a semver field could control how peru reup updates the rev, but the rev would remain the sole source of truth for peru sync. On the other hand you have projects that omit rev because they want “always up-to-date dependencies/resources without any maintenance steps at all” or something like that. In that case, a semver field could affect the revision chosen by peru sync.

Hologoscommented, Oct 3, 2018

If the versions are available as git branches or tags, peru already supports fetching them. For example, this is valid:

git module rack:
   rev: 1.4.1

The problem is, it will only fetch 1.4.1. What I need is when I speficy version: 1.4, it fetches 1.4.* only, never 1.5 and higher.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Semantic Versioning 2.0.0 | Semantic Versioning
Semantic Versioning Specification (SemVer) · Software using Semantic Versioning MUST declare a public API. · A normal version number MUST take the form...
Read more >
A Guide to Semantic Versioning - Baeldung
Explore a quick guide to using and interpreting the SemVer specification. ... Versions help developers keep track of changes to third-party ...
Read more >
Introduction to Semantic Versioning - GeeksforGeeks
Semantic versioning (also known as SemVer) is a versioning system that has been on the rise over the last few years.
Read more >
Semantic Versioning - Read the Docs
The last version of semver which supports Python 2.7 to 3.5 will be 2. ... We recommend to upgrade your workflow to Python...
Read more >
semver - npm
The options supported are: loose Be more forgiving about not-quite-valid semver strings. (Any resulting output will always be 100% strict ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found