19. Make repository resource a hash

[Note, a separate "Make repository more machine readable" proposal
has been merged into this one.]


Currently we have a simple URL for the repository contained in the
resources/repository key. It would be good if more information could be
specified in order to allowed automated tools to do manipulations on the
repository rather than the shipped distribution

I suggest that we (optionally?) allow a hash of data to be stored in

* A distinct URL for the web front end to the repsotitory and the
repository itself

* The repository format (cvs, svn, darcs, git, etc)

* The repository type (free form string, but I'm thinking "sourceforce"
"github" etc, that would allow automated tools that know how to use
repositories that function like those webhosts to do the right thing

For example:

web: http://github.com/2shortplanks/test-time-hires
url: git://github.com/2shortplanks/test-time-hires.git
format: git
type: github


* Should format be constrained? (Dagolden)

* What would format actually mean? (AdamKennedy)

* "format" would indicate which version control system to disambiguate http
urls. E.g. an http URL could be a subversion repo or a git repo (which
doesn't require a ".git" suffix). (Dagolden)

* Is it possible that a distribution has multiple repositories? Note that
www.ohloh.net allows multiple "enlistments" per project. (SlavenRezic)

* A proviso for branch-names and purposes ( or just names ) might also wish
to be considered, (kentnl) ie:

- format: git
url: http://git.example.com/some-repo.git
browser: http://gitweb.example.com/?p=some-repo.git
purpose: releases
branch: releases
- format: git
url: http://git.example.com/some-repo.git
browser: http://gitweb.example.com/?p=some-repo.git
purpose: "patches to"
branch: master

* The repository is meant to be a permanent resources and could be listed
for years, branches are by definition ephemeral and will go away,
recommend against the branches --Adam K

* After thinking about this for a while I wonder if we should keep the use
of repostiory as it is now and add a second key called "version-control"
that has the broken down info. This would make our META.yml more
verbose, but would mean that it was backwards compatible with clients
that only know how to read plain strings in repository

Search Discussions

Discussion Posts

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 1 of 23 | next ›
Discussion Overview
groupcpan-workers @
postedOct 9, '09 at 11:51a
activeNov 4, '09 at 11:31p



site design / logo © 2021 Grokbase