pmxbot IRC Log Viewer

[02:14:42] <bn_work> hi, I seem to have pip installed via homebrew and noticed though I do not have a `pip` but only `pip2` and `pip2.7`. Is this normal?

[02:15:34] <bn_work> pip2 -> ../Cellar/python/2.7.14/bin/pip2

[02:15:34] <bn_work> pip2.7 -> ../Cellar/python/2.7.14/bin/pip2.7

[02:15:40] <sumanah> Hi bn_work

[02:15:53] <sumanah> bn_work: I'm not used to Homebrew but that seems odd to me

[02:16:11] <bn_work> yeah

[02:16:38] <sumanah> bn_work: how long has it been like that?

[02:16:44] <bn_work> not sure

[02:16:55] <dstufft> tdsmith: ^

[02:17:05] <dstufft> is that related to the recent Homebrew thing

[02:17:09] <bn_work> the symlinks have a timestamp of Dec 12

[02:17:43] <bn_work> "Dec 12 [2017]" I'm guessing

[02:17:56] <bn_work> dstufft: what do you mean?

[02:18:06] <dstufft> oh i was asking tdsmith

[02:21:58] <bn_work> hmm, looks like it is a Homebrew thing? https://docs.brew.sh/Homebrew-and-Python.html

[02:22:16] <bn_work> when I do `brew info python` it talks of pip2

[02:24:48] <bn_work> (asking right now in #machomebrew)

[02:25:02] <bn_work> dstufft: so this wasn't always the case?

[02:28:02] <bn_work> I wonder if it's to denote python2.X's pip VS python3.X's pip?

[02:29:19] <toad_polo> There was recently something where Homebrew tried to switch the default python to python 3

[02:29:40] <toad_polo> But then they lost the courage of their convictions I guess.

[02:30:04] <toad_polo> Seems like it might be related to that.

[02:30:37] <bn_work> yeah, looks like the default "python" package refers to python3

[02:31:24] <toad_polo> I thought they reversed that.

[02:38:10] <bn_work> hmm, their documentation on the page is a bit confusing

[02:38:20] <bn_work> > Homebrew provides one formula for Python 3.x (python) and another for Python 2.7.x (python@2).

[02:38:42] <bn_work> > python points to Homebrew’s Python 2.7.x (if installed) otherwise the macOS system Python. Check out brew info python if you wish to add Homebrew’s 3.x python to your PATH.

[02:41:15] <bn_work> no one is saying anything in #machomebrew :/

[02:41:26] <bn_work> there is also this which I'm confused about:

[02:41:45] <bn_work> > The normal pip install --user is disabled for brewed Python. This is because of a bug in distutils, because Homebrew writes a distutils.cfg which sets the package prefix.

[02:41:45] <bn_work> >

[02:41:45] <bn_work> > A possible workaround (which puts executable scripts in ~/Library/Python/<X>.<Y>/bin) is:

[02:56:51] <tdsmith> "python" in homebrew still means python34

[02:56:53] <tdsmith> er

[02:56:54] <tdsmith> python3

[02:57:12] <tdsmith> the python@2 package will give you a pip2 and a pip2.7, probably.

[02:57:22] <tdsmith> anyway the answer to "when" is "recently"

[02:59:37] <sumanah> I wish you well, bn_work!

[03:00:00] <sumanah> hope you figure it out and fix it

[03:00:24] <sumanah> also bn_work you may want to subscribe to https://mail.python.org/mm3/mailman3/lists/pypi-announce.python.org/ to get a heads-up when we make some large PyPI switches in the next few months

[03:00:48] <bn_work> sumanah: thanks, no one in #machomebrew has said anything so I just made a symlink from pip to pip2 and moved on in my life for now, unless I'm told otherwise :)

[05:25:16] <pombreda> !logs

[05:25:16] <pmxbot> http://kafka.dcpython.org/channel/pypa

[11:07:05] <akemot> is there any naming case-sensitivity in package management related tools, or will it be?

[11:08:24] <akemot> i mean for package names only

[11:09:39] <Wooble> that's rather vague.

[11:10:02] <akemot> asking because names in index and JSONs are not normalized

[11:10:11] <akemot> Django instead of django

[11:10:47] <Wooble> if you're asking whether someone could upload "django" and get people with bad requirements files to get the wrong package, no...

[11:12:29] <akemot> that i know, but i've heard there will be kind of some new rules for name normalization

[11:12:50] <akemot> maybe, everything should be lower case

[11:14:33] <ronny> akemot: package names are normalized as per definition in the pep about it (i forgot the number)

[11:14:50] <ronny> baasically case and hypens, underscores/spaces get normalized

[11:15:01] <Wooble> Oh. I've never heard anything about that, but I could have missed it. They're certainly not being casefolded now.

[11:15:47] <ronny> for example, if you go to https://pypi.org/simple/Django/ it redirects automatically to https://pypi.org/simple/django/

[11:16:47] <Wooble> ah, guess it only affects the simple/ interface; the project page is happy to keep the capital.

[11:17:45] <akemot> okay thus, i can assume lower case everywhere if doing something programmatically

[11:18:44] <akemot> it can speed up things when working on package indexes

[11:29:58] <akemot> btw, in pip.get_installed_distributions() result names are not case folded

[11:47:23] <toad_polo> akemot: What is the result of that?

[11:48:13] <akemot> a tree of objects describing installed packages

[11:48:50] <toad_polo> No I mean you shouldn't really be importing pip at all

[11:49:51] <akemot> well, that's the way 'pipdeptree' or pip-tools works

[11:49:56] <toad_polo> Does it affect any of the CLI commands negatively?

[11:50:09] <akemot> why shouldn't I?

[11:51:47] <toad_polo> I mean, I wouldn't expect it to.

[11:51:51] <akemot> instead of "import pip" people reinvent wheel on stackoverflow trying to implement what's already done

[11:52:29] <Wooble> akemot: the problem is that pip doesn't have a stable public API and a new release can feel free to break your tools that import it.

[11:53:30] <akemot> that's a good point, but it works for 2.x and 3.x

[11:57:02] <akemot> and as i said, any cli that you use everyday deals with import pip internally

[11:57:21] <toad_polo> That's not true really.

[11:57:54] <toad_polo> But pip is not a library. It can and does break its internal API regularly.

[11:58:39] <toad_polo> If there is a lot of need for pip's internal functions, maybe someone should write a library that does that, possibly by forking all the interesting stuff out of pip.

[11:59:06] <Wooble> https://github.com/naiquevin/pipdeptree/issues/83

[11:59:17] <toad_polo> Anyway, I wouldn't expect the distribution retrieval function to case fold.

[11:59:25] <toad_polo> Since that is a lossy process.

[12:00:01] <toad_polo> I'd expect case folding to happen immediately before any case insensitive operation like comparison or lookup.

[12:01:47] <akemot> case folding is not a question, because folding would break deps and things

[12:03:51] <akemot> Woobl_ gave a nice link, sounds like pip._internal is all the guts

[12:04:08] <Wooble> I *think* that applies to pip 10.

[12:04:54] <akemot> btw, "forking useful stuff" is kind of excessive considering pip already includes 'vendor' folder with 3rd party goods

[12:08:38] <toad_polo> akemot: Well it's not excessive since pip also is not a library and the options are fork it or reimplement it if you want that functionality.

[12:09:23] <toad_polo> In pip 10 all functions under pip are moving to _internal to make it explicit that none of it is to be used.

[12:10:52] <toad_polo> Anyone has the option to maintain a "piplib" library or something that actually exposes this functionality.

[12:12:40] <akemot> i got it. you want piplib and pip-cli

[12:14:04] <toad_polo> Well pip is already a cli tool.

[12:14:25] <toad_polo> It happens to be written in Python and as a consequence its internal API is discoverable in the standard PYTHONPATH.

[12:15:41] <toad_polo> But that is an unfortunate consequence of the nature of private interfaces in Python, namely that they are "gentleman's agreement", not enforced.

[12:16:37] <toad_polo> If importing pip is widely done, that suggests to me that there is an unfilled niche for a library that does whatever people can't do with subprocess calls to the pip cli.

[15:01:21] <pombreda> Hiya! How do I make a beta version that's semver ? Using 2.9.1.b1 ends up creating a wheel that's 2.9.1b1 which is not semver?

[15:02:08] <mgedmin> https://www.python.org/dev/peps/pep-0440/#public-version-identifiers says no dot in front of "b1"

[15:02:59] <pombreda> mgedmin, ok, thx, but then the version will still be 2.9.1b1 in and 2.9.1b1 out which is not semver?

[15:03:28] <pombreda> mgedmin, should I use a .devX suffix then?

[15:03:28] <mgedmin> afaict semver wants 2.9.1-b1 and you can't have that from python packaging tools

[15:03:39] <pombreda> ack. ouch

[15:03:42] <dstufft> you want a setuptools feature request to not normalize

[15:03:47] <dstufft> https://github.com/pypa/setuptools/issues/308

[15:04:12] <pombreda> hum

[15:04:14] <mgedmin> ah, I see pep-440 allows the - in front of b1

[15:04:18] <mgedmin> https://www.python.org/dev/peps/pep-0440/#pre-release-separators

[15:05:41] <pombreda> dstufft, mgedmin in the end, some of my non-python users complained that my beta version are not semver

[15:05:42] <dstufft> Yea, the list of what is acceptable is larger than what is the "normal" form, all compliant tooling should treat 2.9.1-b1 the same as 2.9.1b1

[15:05:43] <dstufft> pombreda: problem is just that setuptools is forcing the normalization

[15:06:08] <mgedmin> pombreda: tell them this'll be fixed in the final release :P

[15:06:15] <pombreda> so I just need something to state this: this version is a pre-release/development of a future stable version, and I want this semver

[15:06:33] <pombreda> I am not too hung up or beta or else

[15:06:47] <pombreda> let me try .devx

[15:07:00] <dstufft> I think semver requires all pre-releases to use -<whatever>

[15:07:11] <mgedmin> yeah, https://semver.org/#spec-item-9

[15:09:24] <pombreda> ok, so 2.9.1.dev1 ends up as-is in the built wheel alright

[15:09:31] <pombreda> let me try to make this semver

[15:11:21] <pombreda> no luck alright 2.9.1-dev1 ends up 2.9.1.dev1

[15:11:53] <mgedmin> can you rename the wheel file by hand after building it?

[15:12:11] <dstufft> you'll need to reach inside and adjust the metadata too

[15:12:33] <pombreda> yeah, too much involved

[15:12:47] <pombreda> dstufft, mgedmin I may just just plain versions number for now.

[18:13:39] <pombreda> dstufft, mgedmin thanks for the input. I went with a plain version that's semver and not a pre/beta for now. https://github.com/nexB/scancode-toolkit/issues/972

Log file Viewer

Help | Karma | Search:

#pypa logs for Thursday the 22nd of March, 2018