<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/17/2018 07:46 AM, Daniel Alley
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAK1D4mA8kFYPqyb5QqaLv-gtxpKYnq7FPjNBQrypzWAhREviEg@mail.gmail.com">
      <div dir="ltr">
        <div>Some content types are not going to be compatible with the
          normal sync/publish/distribute Pulp workflows, and will need
          to be live API-only.  To what degree should Pulp accomodate
          these use cases?<br>
        </div>
        <div><br>
        </div>
        <div>Example:  <br>
        </div>
        <div><br>
        </div>
        <div>Pulp makes the assumptions that <br>
        </div>
        <div><br>
        </div>
        <div>A) the metadata for a repository can be generated in its
          entirety by the known set of content in a RepositoryVersion,
          and</div>
        <div><br>
        </div>
        <div>B) the client wouldn't care if you point it at an older
          version of the same repository.  <br>
        </div>
        <div><br>
        </div>
        <div>Cargo, the package manager for the Rust programming
          language, expects the registry url to be a git repository. 
          When a user does a "cargo update", cargo essentially does a
          "git pull" to update a local copy of the registry.<br>
        </div>
        <div><br>
        </div>
        <div>Both of those assumptions are false in this case. You
          cannot generate the git history just from the set of content,
          and you cannot "roll back" the state of the repository without
          either breaking it for clients, or adding new commits on top.<br>
        </div>
        <div><br>
        </div>
        <div>A theoretical Pulp plugin that worked with Cargo would need
          to ignore almost all of the existing Pulp primitives and very
          little (if any) of the normal Pulp workflow could be used.<br>
        </div>
        <div><br>
        </div>
        <div>Should Pulp attempt to cater to plugins like these?  What
          could Pulp do to provide a benefit for such plugins over
          writing something from scratch from the ground up?  To what
          extent would such plugins be able to integrate with the rest
          of Pulp, if at all?</div>
      </div>
    </blockquote>
    <br>
    I think OSTree and Ansible plugins will be in the same boat as
    Cargo.  In the case of OSTree, libostree does the heavy lifting for
    sync and publishing and I suspect the same is true for Git based
    repositories.  We should consider way to best support distributing
    (serving) content in core for these content types.  I suspect this
    will mainly entail something in the content app and perhaps a new
    component of a Publication like PublishedDirectory that references
    an OSTree/Git repository created in /var/lib/pulp/published.  This
    may benefit Maven as well.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAK1D4mA8kFYPqyb5QqaLv-gtxpKYnq7FPjNBQrypzWAhREviEg@mail.gmail.com">
      <div dir="ltr">
        <div><br>
        </div>
        <div>We don't have to commit to anything pre-GA but it is a good
          thing to keep in mind.  I'm sure there are other content types
          out there (not just Cargo) which would face similar problems. 
          pulp_git was inquired about a few months ago, it seems like it
          would share a few of them.</div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Pulp-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/pulp-dev">https://www.redhat.com/mailman/listinfo/pulp-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>