FAQ
19. Make repository resource a hash

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

Proposal:

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
repository:

* 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:

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

Comments:

* 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:

repository:
- 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

  • Ricardo Signes at Oct 9, 2009 at 1:15 pm
    * David Golden [2009-10-09T07:51:06]
    19. Make repository resource a hash

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

    --
    rjbs
  • Shlomi Fish at Oct 10, 2009 at 4:54 pm

    On Friday 09 Oct 2009 15:14:55 Ricardo Signes wrote:
    * David Golden [2009-10-09T07:51:06]
    19. Make repository resource a hash

    [Note, a separate "Make repository more machine readable" proposal
    has been merged into this one.]
    Agreed.
    Doesn't sound too bad. +1.

    Regards,

    Shlomi Fish

    --
    -----------------------------------------------------------------
    Shlomi Fish http://www.shlomifish.org/
    Original Riddles - http://www.shlomifish.org/puzzles/

    Chuck Norris read the entire English Wikipedia in 24 hours. Twice.
  • Graham Barr at Oct 9, 2009 at 2:13 pm

    On Oct 9, 2009, at 6:51 AM, David Golden wrote:

    19. Make repository resource a hash


    resources:
    repository:
    web: http://github.com/2shortplanks/test-time-hires
    url: git://github.com/2shortplanks/test-time-hires.git
    format: git
    type: github
    +1
  • David E. Wheeler at Oct 9, 2009 at 6:20 pm

    On Oct 9, 2009, at 7:12 AM, Graham Barr wrote:

    resources:
    repository:
    web: http://github.com/2shortplanks/test-time-hires
    url: git://github.com/2shortplanks/test-time-hires.git
    format: git
    type: github
    +1
    +1, though I think I'd use "vcs" instead of "format".

    Best,

    David
  • Steffen Mueller at Oct 9, 2009 at 2:31 pm

    David Golden wrote:
    19. Make repository resource a hash
    +1

    Steffen
  • David Golden at Oct 9, 2009 at 8:21 pm

    On Fri, Oct 9, 2009 at 7:51 AM, David Golden wrote:
    19. Make repository resource a hash
    resources:
    repository:
    web: http://github.com/2shortplanks/test-time-hires
    url: git://github.com/2shortplanks/test-time-hires.git
    format: git
    type: github
    +1, though I'd drop "type". I don't have strong opinions over whether
    "format" is renamed to "vcs" or whatever.

    -- David
  • Graham Barr at Oct 9, 2009 at 8:55 pm

    On Oct 9, 2009, at 3:21 PM, David Golden wrote:
    On Fri, Oct 9, 2009 at 7:51 AM, David Golden wrote:
    19. Make repository resource a hash
    resources:
    repository:
    web: http://github.com/2shortplanks/test-time-hires
    url: git://github.com/2shortplanks/test-time-hires.git
    format: git
    type: github
    +1, though I'd drop "type". I don't have strong opinions over whether
    "format" is renamed to "vcs" or whatever.
    yeah I agree. I was too wondering why two fields. I nearly suggested
    dropping
    type as-is, but renaming format as type

    Graham.
  • David E. Wheeler at Oct 9, 2009 at 10:15 pm

    On Oct 9, 2009, at 1:55 PM, Graham Barr wrote:

    repository:
    web: http://github.com/2shortplanks/test-time-hires
    url: git://github.com/2shortplanks/test-time-hires.git
    format: git
    type: github
    +1, though I'd drop "type". I don't have strong opinions over
    whether
    "format" is renamed to "vcs" or whatever.
    yeah I agree. I was too wondering why two fields. I nearly suggested
    dropping
    type as-is, but renaming format as type
    Yes, that's better. +1

    David
  • Barbie at Oct 31, 2009 at 6:05 pm

    On Fri, Oct 09, 2009 at 04:21:21PM -0400, David Golden wrote:
    On Fri, Oct 9, 2009 at 7:51 AM, David Golden wrote:
    19. Make repository resource a hash
    resources:
    repository:
    web: http://github.com/2shortplanks/test-time-hires
    url: git://github.com/2shortplanks/test-time-hires.git
    format: git
    type: github
    +1, though I'd drop "type". I don't have strong opinions over whether
    "format" is renamed to "vcs" or whatever.
    Agreed on both counts. "type" as proposed can be easily derived from the
    URLs from the examples. Is there a use case for its use?

    Cheers,
    Barbie.
    --
    Birmingham Perl Mongers <http://birmingham.pm.org>
    Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>
    CPAN Testers Blog <http://blog.cpantesters.org>
    YAPC Conference Surveys <http://yapc-surveys.org>
  • David Golden at Oct 31, 2009 at 7:45 pm

    On Sat, Oct 31, 2009 at 2:05 PM, Barbie wrote:
    Agreed on both counts. "type" as proposed can be easily derived from the
    URLs from the examples. Is there a use case for its use?
    Both Subversion, and Git repositories can use "http://" URLs, so there
    needs to disambiguate them.

    David
  • Ricardo Signes at Oct 31, 2009 at 8:15 pm
    * David Golden [2009-10-31T15:45:31]
    On Sat, Oct 31, 2009 at 2:05 PM, Barbie wrote:
    Agreed on both counts. "type" as proposed can be easily derived from the
    URLs from the examples. Is there a use case for its use?
    Both Subversion, and Git repositories can use "http://" URLs, so there
    needs to disambiguate them.
    I believe the question was about "type: github" which is not useful. A type
    for git v. svn is crucial.

    --
    rjbs
  • Barbie at Oct 31, 2009 at 9:21 pm

    On Sat, Oct 31, 2009 at 03:45:31PM -0400, David Golden wrote:
    On Sat, Oct 31, 2009 at 2:05 PM, Barbie wrote:
    Agreed on both counts. "type" as proposed can be easily derived from the
    URLs from the examples. Is there a use case for its use?
    Both Subversion, and Git repositories can use "http://" URLs, so there
    needs to disambiguate them.
    No. I meant "type" not "format". In the example given, the URL was
    http://github.com and the type was "github". It seemed a bit redundant
    to explicitly say what public website repository is being used, when it
    was in the domain part of the URL.

    Cheers,
    Barbie.
    --
    Birmingham Perl Mongers <http://birmingham.pm.org>
    Memoirs Of A Roadie <http://barbie.missbarbell.co.uk>
    CPAN Testers Blog <http://blog.cpantesters.org>
    YAPC Conference Surveys <http://yapc-surveys.org>
  • Ricardo Signes at Oct 10, 2009 at 2:33 am
    * David Golden [2009-10-09T07:51:06]
    19. Make repository resource a hash
    Branch available:
    http://github.com/rjbs/cpan-meta-spec/commits/19-repository-hash

    --
    rjbs
  • David Golden at Oct 10, 2009 at 11:01 am

    On Fri, Oct 9, 2009 at 10:33 PM, Ricardo Signes wrote:
    * David Golden [2009-10-09T07:51:06]
    19. Make repository resource a hash
    Branch available:
    http://github.com/rjbs/cpan-meta-spec/commits/19-repository-hash
    Seems to me that url and type should be mandatory and web should be optional.

    -- David
  • Ricardo Signes at Oct 10, 2009 at 11:46 am
    * David Golden [2009-10-10T07:00:52]
    On Fri, Oct 9, 2009 at 10:33 PM, Ricardo Signes
    wrote:
    * David Golden [2009-10-09T07:51:06]
    19. Make repository resource a hash
    Branch available:
    http://github.com/rjbs/cpan-meta-spec/commits/19-repository-hash
    Seems to me that url and type should be mandatory and web should be optional.
    This won't work in cases where the underlying VCS is private but a browser
    exists. (Imagine if pre-git we had a p4 history browser for perl.)

    --
    rjbs
  • Slaven Rezic at Nov 1, 2009 at 7:01 pm

    David Golden wrote:
    19. Make repository resource a hash

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

    Proposal:

    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
    repository:

    * 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:

    resources:
    repository:
    web: http://github.com/2shortplanks/test-time-hires
    url: git://github.com/2shortplanks/test-time-hires.git
    format: git
    type: github
    "url" is not enough to describe how to checkout from a CVS repository.
    At least username and password (for "cvs login") and url and module (for
    "cvs -d url co module") are needed.

    Do we need the distinction between anonymous (read-only) and read-write
    access? Or should be assume that only the read-only specification is
    necessary?

    Regards,
    Slaven
  • David Golden at Nov 1, 2009 at 7:15 pm

    On Sun, Nov 1, 2009 at 2:01 PM, Slaven Rezic wrote:
    "url" is not enough to describe how to checkout from a CVS repository. At
    least username and password (for "cvs login") and url and module (for  "cvs
    -d url co module") are needed.
    Can you give a specific example? We're in overtime for finalizing the
    spec, so we need to nail this quick.
    Do we need the distinction between anonymous (read-only) and read-write
    access? Or should be assume that only the read-only specification is
    necessary?
    I'd argue the latter for things that distinguish.

    David
  • Slaven Rezic at Nov 1, 2009 at 8:11 pm

    David Golden wrote:
    On Sun, Nov 1, 2009 at 2:01 PM, Slaven Rezic wrote:
    "url" is not enough to describe how to checkout from a CVS repository. At
    least username and password (for "cvs login") and url and module (for "cvs
    -d url co module") are needed.
    Can you give a specific example? We're in overtime for finalizing the
    spec, so we need to nail this quick.
    For cvs we don't need the url parameter but rather:

    repository => {
    type => "cvs",
    vc_spec => {
    username => "anonymous",
    password => "",
    repository =>
    ":pserver:anonymous@srezic.cvs.sourceforge.net:/cvsroot/srezic",
    module => "Tk-Pod",
    port => undef, # set if different from standard 2401
    },
    web => ...,
    ...
    }

    The contents inside vc_spec are completely VC-specific. For CVS it would
    be these parameters, other VCs could have other parameters (sorry, I
    don't know anything else but cvs, svn, and git).

    Theoretetically the URL needed for svn or git could also go into such a
    vc_spec structure, but this would probably be too complicated.

    Do we need the distinction between anonymous (read-only) and read-write
    access? Or should be assume that only the read-only specification is
    necessary?
    I'd argue the latter for things that distinguish.
    I think it's also sufficient. But there should probably be a note in the
    META specification that the read-only repository is meant.

    Regards,
    Slaven
  • Slaven Rezic at Nov 4, 2009 at 11:31 pm

    Slaven Rezic wrote:
    David Golden wrote:
    On Sun, Nov 1, 2009 at 2:01 PM, Slaven Rezic wrote:
    "url" is not enough to describe how to checkout from a CVS
    repository. At
    least username and password (for "cvs login") and url and module
    (for "cvs
    -d url co module") are needed.
    Can you give a specific example? We're in overtime for finalizing the
    spec, so we need to nail this quick.
    For cvs we don't need the url parameter but rather:

    repository => {
    type => "cvs",
    vc_spec => {
    username => "anonymous",
    password => "",
    repository =>
    ":pserver:anonymous@srezic.cvs.sourceforge.net:/cvsroot/srezic",
    module => "Tk-Pod",
    port => undef, # set if different from standard 2401
    },
    web => ...,
    ...
    }

    The contents inside vc_spec are completely VC-specific. For CVS it would
    be these parameters, other VCs could have other parameters (sorry, I
    don't know anything else but cvs, svn, and git).

    Theoretetically the URL needed for svn or git could also go into such a
    vc_spec structure, but this would probably be too complicated.
    Ah, there's already prior art. www.ohloh.net also needs the source
    repository (they call it "enlistment") fully specified. Here's what may
    be entered in ohloh's forms:

    CVS:
    Enter the source control URL (e.g.
    :pserver:anonymous:@myproject.cvs.sourceforge.net:/cvsroot/myproject)
    Username
    Password
    CVS module name

    SVN:
    Enter the source control URL (e.g.
    svn://mywebsite.org/svn/myproject/trunk)
    Username
    Password

    Mercurial:
    Enter the source control URL (e.g.
    http://www.mywebsite.org/pub/scm/hg/myproject)

    Git:
    Enter the source control URL (e.g.
    git://git.mywebsite.org/pub/scm/git/myproject.git)
    Enter an optional Git branch name

    Bazaar:
    Enter the source control URL (e.g. bzr://www.mywebsite.org/myproject.bzr)


    So I think the optional branch for git should be added to the spec.
  • David Cantrell at Nov 3, 2009 at 1:41 pm

    On Sun, Nov 01, 2009 at 08:01:50PM +0100, Slaven Rezic wrote:
    David Golden wrote:
    resources:
    repository:
    web: http://github.com/2shortplanks/test-time-hires
    url: git://github.com/2shortplanks/test-time-hires.git
    format: git
    type: github
    "url" is not enough to describe how to checkout from a CVS repository.
    At least username and password (for "cvs login") and url and module (for
    "cvs -d url co module") are needed.
    Do we need the distinction between anonymous (read-only) and read-write
    access? Or should be assume that only the read-only specification is
    necessary?
    If you think I'm putting a username/password for read/write access to my
    repo into META.yml, you're dead wrong!

    --
    David Cantrell | top google result for "internet beard fetish club"

    " In My Egotistical Opinion, most people's ... programs should be
    indented six feet downward and covered with dirt. "
    --Blair P. Houghton
  • Slaven Rezic at Nov 4, 2009 at 11:22 pm

    David Cantrell wrote:
    On Sun, Nov 01, 2009 at 08:01:50PM +0100, Slaven Rezic wrote:
    David Golden wrote:
    resources:
    repository:
    web: http://github.com/2shortplanks/test-time-hires
    url: git://github.com/2shortplanks/test-time-hires.git
    format: git
    type: github
    "url" is not enough to describe how to checkout from a CVS repository.
    At least username and password (for "cvs login") and url and module (for
    "cvs -d url co module") are needed.
    Do we need the distinction between anonymous (read-only) and read-write
    access? Or should be assume that only the read-only specification is
    necessary?
    If you think I'm putting a username/password for read/write access to my
    repo into META.yml, you're dead wrong!
    We're talking here about public repositories. Sourceforge for instance
    uses username=anonymous and password=<empty> for anonymous access. I've
    seen other CVS repos with some dummy non-empty password.

    Regards,
    Slaven
  • Mark Fowler at Nov 3, 2009 at 9:13 am
    Hi,

    The patch for repository resource as a hash accidentally obliterated
    from the spec the old way of doing things (so the spec as it stands
    doesn't document a single entry at all, which if nothing else, new
    parsers should support for backwards compatibility)

    As discussed with rjbs on irc, I've prepared a patch for the patch for
    consideration which fixes this.

    http://github.com/2shortplanks/cpan-meta-spec/commit/64e43b01cebae3c9f684dae23450f6fc67353f03

    (You'll probably also want to take it's parent
    http://github.com/2shortplanks/cpan-meta-spec/commit/c5aa22393c3da8dc569641ff047e216b95eeab42
    which is a fix for a spelling mistake)

    Mark.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedOct 9, '09 at 11:51a
activeNov 4, '09 at 11:31p
posts23
users10
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase