SemVer supportSee original GitHub issue
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.
imports: rack_example: rack/ # This is where we want peru to put the module. git module rack_example: url: git://github.com/chneukirchen/rack.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).
- Created 5 years ago
- Comments:20 (10 by maintainers)
Top GitHub Comments
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
If the versions are available as git branches or tags, peru already supports fetching them. For example, this is valid:
git module rack: url: https://github.com/chneukirchen/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.