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

Feature/multiple downloads #2

Merged
merged 18 commits into from
Jul 19, 2012
Merged

Feature/multiple downloads #2

merged 18 commits into from
Jul 19, 2012

Conversation

paulswartz
Copy link
Contributor

No rush for merging this, but it is needed for enterprise C.

@melinath
Copy link
Contributor

As per http://bugzilla.pculture.org/show_bug.cgi?id=16718, it might make sense to have file_url_* properties return the favored download rather than the first one. Or alternatively, cache the favored download elsewhere and remove the file_url_* properties. I know, I was the one who suggested they be used as you're now using them, but it might make more sense to just drop them. Do we need them any more?

Conflicts:
	vidscraper/suites/__init__.py
	vidscraper/suites/base.py
	vidscraper/suites/feed.py
	vidscraper/suites/vimeo.py
	vidscraper/suites/youtube.py
	vidscraper/tests/unit/test_generic.py
	vidscraper/tests/unit/test_vimeo.py
	vidscraper/tests/unit/test_youtube.py
Conflicts:
	vidscraper/tests/integration/test_youtube.py
	vidscraper/videos.py
Also removed file_url_* properties, cleaned up feedparser utils, and spread use of VideoFile to the blip and generic suites.
@melinath
Copy link
Contributor

melinath commented Jul 2, 2012

Remaining issues on this pull request:

  • serialization of VideoFile instances.
  • at a minimum, correcting incorrect documentation. Preferably, hand-writing some new docs to cover the multiple files.
  • improve docstrings for VideoFile attributes.
  • restrict setting of attributes on VideoFile.__init__ to the known attributes.
  • rename url_expires to expires.

@melinath
Copy link
Contributor

melinath commented Jul 2, 2012

Also, turns out that assertGreater (used in some updated test cases in this branch) requires unittest2, available natively in 2.7 but not 2.6. I'd be fine with introducing unittest2 as a dependency - or we could use nose's assertions.

@melinath
Copy link
Contributor

melinath commented Jul 6, 2012

I believe that resolves all the issues I mentioned as remaining on this pull request. Paul: Would you be up for/interested in reviewing the changes?

@@ -41,3 +41,6 @@
:func:`vidscraper.handles_feed`, respectively. They now accept the same
parameters as :func:`vidscraper.auto_scrape` and
:func:`vidscraper.auto_feed`.
* Multiple :class:`VideoFile`\ s are now made available for :class:`.Video`
Copy link
Contributor Author

Choose a reason for hiding this comment

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

typo?

Copy link
Contributor

Choose a reason for hiding this comment

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

Just to make sure I'm on the same page as you - the missing . before VideoFile and later before Video? Something about the "made available" wording?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That just looks like a strange line, but I guess as long as it renders correctly then it's okay.

Copy link
Contributor

Choose a reason for hiding this comment

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

It renders as intended. Fixed the missing . with b019289.

@paulswartz
Copy link
Contributor Author

I'm not thrilled with the decision to totally drop file_url but it's not really my library anymore. Is there a reason to not keep it around, even as a property?

@melinath
Copy link
Contributor

melinath commented Jul 7, 2012

Thanks for looking over this. The reasoning is that there should be one way and only one way to get at the first file. I also am not entirely convinced of the usefulness of being able to get at the first file as opposed to being able to get at the preferred file. I've been thinking of rolling bug 17716 and bug 16718 into 0.6 as a get_file method that returns the best available file from the list, determined by mimetype - but I want to do that as a separate branch.

Is there any reason to keep it around as a property that I'm not seeing?

@paulswartz
Copy link
Contributor Author

The reason to keep it around would be so that a point upgrade to Vidscraper doesn't totally break people who are using it. But, IIRC there are a bunch of other backwards-incompatible changes in 0.6 so just documenting the change, and what the new code should look like, is okay.

@melinath
Copy link
Contributor

melinath commented Jul 7, 2012

Opened a ticket for documenting backwards-incompatibilities. We do have the release notes, but more targeted documentation would be better.

@melinath
Copy link
Contributor

I believe I've addressed all comments with either a commit or an explanation. Let me know if there are any outstanding or continued concerns. I'll merge this on Wednesday barring further comment.

@melinath melinath merged commit b019289 into develop Jul 19, 2012
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