@alalazo @tgamblin Another random Travis failure. Seems to be getting more frequent lately.
https://travis-ci.org/LLNL/spack/jobs/176425363

@adamjstewart Is there an issue open on those random failures ? If not can you open it and link at least the PRs where it happened ? I think it would be good to see if the causes are always the same. In this case it seems something related to the fetchers.

@alalazo How do I look up the URL for the Travis build that failed?

If people didn't force push, I guess you can just click on the X sign next to the failing commit. If people did force push you have to check build-history in LLNL/Travis manually (or at least that's what I do...).

It looks like even if you close and reopen, it overwrites the X with a new check.

Ping @tgamblin @becker33

Ping @tgamblin

This looks good to me, but @tgamblin is more familiar with the namespace feature so I'll probably leave it until he gets a chance to look at it.

Ping @tgamblin. This will help keep things uniform, in line with #2475.

@becker33: this isn't actually about namespaces, just packages that have . in the URL.

@adamjstewart: This looks good, I'm just curious whether you think it would be better to handle the conversion of _ and . to - outside of parse_name_offset, in case we ever want to recover the original name from the tarball. Seems like it would be simpler to keep the existing parse_name_offset functionality and wrap the choices we've made w.r.t. package name formats up into a sanitize_package_name function, instead of putting them together.

@tgamblin I'll leave it up to you. I'm not sure what the original tarball name would be useful for, but you're welcome to push any changes to my branch. My only request is that my changes to the url_parse tests remain in effect. That would mean any calls to url.parse_name_and_version should return the sanitized name.

Ok I thought about this more. I actually like the consistency and don't feel like adding a special case we're not likely to use.