Allow filesystem uploads

[waldoj]

Although not useful to me, I appreciate that, for many people, the videos that they wish to upload to YouTube will already be on their system. I suggest that, when a path (relative or absolute) is passed in place of a URL, that the video be uploaded from there (and not deleted afterwards).

[copiesofcopies]

Yes, good idea. The question is how to distinguish URLs from (cross-platform) local paths. This suggests it's actually quite difficult, maybe even practically impossible. Would adding an additional field to the metadata pose any problems that you can think of? Or can you think of another way to do this?

[waldoj]

Well, there's validating a URL and there's detecting a URL. There are only two valid paths for a WWW URL, and both start with http(s?)://. So the lazy (but not unreasonable) approach might be to say that if the path starts with http(s?)://, then it's remote, otherwise it's local. That can be double-checked with if os.path.exists(url).

OTOH, urllib.urlretrieve supports local file retrieval:

If the URL points to a local file, or a valid cached copy of the object exists, the object is not copied.

It's not clear to me whether it returns an error or, instead, happily returns a tuple for the file at its existing location. But I suppose people could just use a file:// URL. It's not very Unix-y, but it has the benefit of possibly working already. :)

[copiesofcopies]

I guess I was thinking we'd want to at least support ftp as well as http, but I guess the universe of acceptable URLs I'd pretty limited. I'll give urlretrieve's local path handling a shot -- forgot about that.

Waldo Jaquith notifications@github.com wrote:

Well, there's validating a URL and there's detecting a URL. There
are only two valid paths for a WWW URL, and both start with
http(s?)://. So the lazy (but not unreasonable) approach might be to
say that if the path starts with http(s?)://, then it's remote,
otherwise it's local. That can be double-checked with if
os.path.exists(url).

OTOH, urllib.urlretrieve supports local file
retrieval:

If the URL points to a local file, or a valid cached copy of the
object exists, the object is not copied.

It's not clear to me whether it returns an error or, instead, happily
returns a tuple for the file at its existing location. But I suppose
people could just use a file:// URL. It's not very Unix-y, but it has
the benefit of possibly working already. :)

---

Reply to this email directly or view it on GitHub:
#6 (comment)

Via mobile

[copiesofcopies]

So, it turns out this already works, at least for me. Want to test on your end?

[waldoj]

Hey, how about that? :) I guess I should have tested that out first, rather than just assuming it wouldn't work. That's great!