Log file Viewer
#pypa logs for Wednesday the 10th of February, 2016
[09:16:07] <ojii|work> I'm doing `pip install --pre <package>` but get "Could not find a version that satisfies the requirement <package> (from versions: 0.2-7d6439e)", how can I install that version?
[09:20:53] <ojii|work> the bit after the dash is a short git hash so it changes all the time, while the tooling to install it is ideally not changed that often
[09:46:35] <ojii|work> xafer: for the record, replacing the '-' with a '+' "fixes" it, don't even need --pre anymore
[09:51:03] <xafer> Yes, that's what is expected if you want to follow https://www.python.org/dev/peps/pep-0440/
[09:52:54] <ojii|work> for context, this is an internal package, not something that will ever be on pypi (or any index server for that matter)
[09:53:06] <ojii|work> pip flat out refusing to install something because it doesn't like the version string seems odd
[10:00:01] <mgedmin> it thinks this is a pre-release, and it refuses to install prereleases unless explicitly asked
[10:01:10] <mgedmin> either pin the version explicitly, or do proper (internal) releases 0.2.1, 0.2.2, ...
[10:07:43] <xafer> And SpecifierSet().filter(['0.2-7d6439e']) returns [] just like SpecifierSet().filter(['fooo'])
[10:11:53] <ojii|work> if `pip wheel` can generate it, IMHO `pip install` should be able to install it
[13:31:18] <haypo> pip._vendor.requests.packages.urllib3.exceptions.SSLError: [Errno 20] Not a directory
[13:53:09] <xafer> dstufft: is the fact that python -c "from packaging import version, specifiers;print(specifiers.SpecifierSet().filter([version.parse('foooo')]))" returns [] normal ? It seems wrong to me
[14:03:24] <dstufft> xafer: specifiers.SpecifierSet().filter(version.contains('foooo')) returns true
[14:03:54] <dstufft> https://github.com/pypa/packaging/blob/master/packaging/specifiers.py#L755-L757 I explicitly excluded things that weren't valid PEP 440 versions from filter()
[14:09:17] <dstufft> Sort of, legacy versions are always kind of weird since they are always less than any valid PEP 440 version, so >=0 would exclude any legacy version but an empty set wouldn't if we removed that clause
[14:10:06] <dstufft> I can't come up with a good reason why I explicitly excluded LegacyVersion though
[14:10:25] <xafer> In pip, this is used here: https://github.com/pypa/pip/blob/develop/pip/index.py#L439-L454
[14:13:53] <dstufft> you'd have to explicitly do something like ``pip install foo<10-not-a-valid-pep440-version`` or something
[14:14:50] <dstufft> and from the PEP Due to the above, this PEP MUST be used for all versions of metadata and supersedes PEP 386 even for metadata v1.2. Tools SHOULD ignore any versions which cannot be parsed by the rules in this PEP, but MAY fall back to implementation defined version parsing and ordering schemes if no versions complying with this PEP are available.
[14:16:10] <dstufft> so right now, packaging implements that so the only time you ever take a non PEP 440 version, is if you explicitly mention a specifier that can only be matched by a non PEP 440 version specifier
[14:16:26] <dstufft> the argument could be made, that we could do a fallback like we do for pre-releases
[14:17:04] <xafer> Currently pip prints out: "Could not find a version that satisfies the requirement <package> (from versions: 0.2-7d6439e)"
[14:20:40] <dstufft> yea, a better error message seems like it'd be good there. Maybe print out a warning if we can't find a suitable version and there exists *only* non PEP 440 versions in the list of available versions?
[14:24:06] <xafer> What would be the suggested solution ? Go read pep440 or drop a random "<zzzzzzzzzz" specifier ? :p
[15:42:23] <meshy> not a problem, just a little curious: a workmate just uploaded a package, but wasn't immediately able to install it ("Could not find a version that satisfies...") -- but I could. After a few minutes, he could install it. Does anyone know what might have caused that? CDN propagation, perhaps?
[17:46:20] <gp> How would I go about specifying a remote tarball plus extra_requires in a requirements.txt file?
[18:26:12] <DRMacIver> So I have what I think might boil down to a packaging problem: Essentially I have a data file that I would like to include in the package but turns out to need to be different per python version. I can just build it inside my setup.py no problem, but will that interact correctly with wheels assuming I don't opt in to universal ones?
[18:28:37] <dstufft> DRMacIver: is it different between 2.x and 3.x? or 2.6, 2.7, 3.3, 3.4, 3.5? Or CPyhton 2.6, Cpython 2.7, PyPy 4.0.1, etc?
[18:30:13] <DRMacIver> (If you're thinking "Man, DRMacIver makes poor life choices" right about now, you're not wrong)
[18:30:56] <dstufft> DRMacIver: if it's CPython 2.6, CPython 2.7, PyPy 4.0. etc then you can just use implemetmnation specifiec tags in your wheel (which uh, I forgot offhand the best way to make that happen.... ) and those will be restricted to a specifiv interpreter version
[18:31:31] <DRMacIver> Note that I don't actually build wheels myself, I just distribute an sdist. I'm mostly interested in interacting correctly with pip's change to automatically build wheels.
[18:31:56] <dstufft> as of pip 8, we always force our automatically built wheels to be specific to the intepreter we're running on
[18:33:21] <dstufft> pip 7.1+ just let the wheels do whatever they want (typicalyl default to pyX for pure python stuff) but that caused issues for projects that weren't setup to handle wheels yet
[18:33:26] <DRMacIver> I think I'll generate this myself and cache it in my own cache directory. It seems like a smaller can of less angry worms.
[19:07:54] <DRMacIver> ronny: Basically a reverse mapping of unicode categories to lists of codepoint intervals.
[19:08:09] <DRMacIver> It's for the Hypothesis characters() strategy which lets you specify which categories to include/exclude
[19:27:13] <Ned_> So I just built a wheel using pip wheel <packagename>, it's put tags of ('cp27', 'cp27mu', 'linux_x86_64') on it
[19:27:34] <Ned_> but when I try to install it, I don't have "cp27mu" in any of my supported tags, so I can't use it ... any know what's up there ?
[19:28:41] <Ned_> curiously, I just tried it with a python3 virtualenv, and it all worked fine, tags were ('cp34', 'cp43m', 'linux_x86_64')
[19:37:55] <dstufft> Ned_: filing an issue along with any relevant steps to reproduce and what your OS/Python is is probably the best bet
[19:38:44] <ronny> my gut is turning around in a very painfull manner when thingking about pulling very useull things out of pytest, because it will send us to version-hell