Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use publishing context manager. #35

Merged
merged 1 commit into from
Feb 5, 2018
Merged

Use publishing context manager. #35

merged 1 commit into from
Feb 5, 2018

Conversation

jortel
Copy link
Contributor

@jortel jortel commented Feb 1, 2018

Copy link
Contributor

@asmacdo asmacdo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is so much simpler, great work.

for content in publication.repository_version.content:
for content_artifact in content.contentartifact_set.all():
artifact = _find_artifact(content_artifact, publication.repository_version.repository)
artifact = find_artifact()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be easier to read if we pass content_artifact, repository as arguments instead of depending on the scope/state.

with Publication.create(repository_version, publisher) as publication:
manifest = Manifest('PULP_MANIFEST')
manifest.write(_publish(publication))
metadata = PublishedMetadata(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had originally hoped this would be accomplished by publication.add_metadata(manifest.path). I don't think its really necessary for the plugin writer to know about and use the PublishedMetadata object, but leaving like this is probably more appropriate since the publication is a django model.

@@ -48,9 +46,16 @@ def _publish(publication):
Yields:
Entry: The manifest entry.
"""
def find_artifact():
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, this function doesn't really need a docstring for the file plugin, but it would be helpful for plugin writers who are using the file plugin as an example. If the plugin writer isn't already totally familiar with deferred downloading, this step could be surprising. (Especially because deferred downloading isn't well documented in Pulp 3 yet.)

@jortel jortel merged commit 0c2d9ef into pulp:master Feb 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants