[03:36:02] <PyDon> can anyone help me? i would like to redistribute pip with my embedded Python installation, but I am surprised that pip itself doesn't distribute the license of wheels/easy_install/pip and also not of the modules within _vendors like urllib3. Is that intended?
[03:37:00] <PyDon> So I am wondering if pip itself doesn't follow the license requirements of these 3rd party modules or if I am overseeing smth
[04:27:12] <McSinyx[m]> PyDon: I'm pretty sure there's a LICENCE.txt file for urllib3, and so is for pip
[04:27:51] <McSinyx[m]> wheel is not a direct dependency of pip though and I'm not sure why you need easy_install with pip
[05:15:45] <PyDon> McSinyx[m] when I install it via get-pip.py I get all these dependencies, and in _vendor there is no LICENSE.txt for any lib, also not for urllib3
[05:16:26] <PyDon> It is in the repo, but not when I install it
[06:26:04] <McSinyx[m]> PyDon: IANAL but since vendor libs are permissive (my guess because pip is licensed under MIT), derivatives like pip may legally imply another terms (that's why permissive are often referred to as hypocrite licenses)
[06:26:34] <McSinyx[m]> that being said, pip's vendoring policy actually required what you asked:
[06:27:16] <McSinyx[m]> I'll join you investigate a bit further to see why vendor lib licensed are not installed
[07:02:59] <McSinyx[m]> oh hi sbidoul do you know why binary distribution don't vendor vendor lib licenses?
[07:03:26] <McSinyx[m]> or is it just something missed out?
[07:28:55] <sbidoul> McSinyx: I can imagine why the licenses do not make it to the pip wheel. I'm not sure what the best approach would be to include them. Better opening an issue on the pip tracker to discuss that.
[07:31:56] <McSinyx[m]> thanks, I don't think it is necessary to do it either, but I'm wondering if that was by design or by mistake
[07:32:27] <McSinyx[m]> i'll open an issue to fulfill my curiosity then
[07:54:01] <McSinyx[m]> PyDon, sbidoul: I've just filed https://github.com/pypa/pip/issues/8330
[08:14:32] <PSFSlack> <deveshkusingh> Hi sbidoul: Great to see you here
[08:21:33] <famubu> Hi. Is there a standard way to change the version of a python package? What I do now is change the value of `__version__` variable in python source and the version inside `setup.py`.
[08:22:14] <McSinyx[m]> famubu: if it's pure python you can try to use flit instead of setuptools
[08:26:50] <famubu> McSinyx[m]: It is pure python but I've already got it done with setuptools.
[08:26:58] <famubu> McSinyx[m]: And is flit preferred over setuptools?
[08:27:20] <McSinyx[m]> I don't think so, it's just another option
[08:27:45] <McSinyx[m]> flit do convinent things like assuming version from <package>.__version__
[08:29:21] <famubu> Is there any standard place to place the __version__ variable?
[08:29:58] <famubu> I currently have it inside an app.py which is called by __main__.py
[08:30:23] <McSinyx[m]> re standard: not that I am aware of
[08:31:40] <McSinyx[m]> personally I recommend you trying out flit if you don't have to use and hack in setup.py
[08:31:42] <famubu> I came across https://pypi.org/project/bumpversion/ and was wondering if people use similar tools to bump up version :-)
[08:33:46] <famubu> McSinyx[m]: I had been thinking of trying out flit. Got to read it up. Does flit and poetry work hand in hand? Or are they completely different?
[08:34:45] <McSinyx[m]> I don't know about poetry enough to tell
[08:35:19] <McSinyx[m]> pip's using bumpversion btw, and I think I've seen it used quite manywhere
[08:35:57] <ronny> flit and poetry are completely different
[08:36:55] <ronny> famubu: setuptools_scm uses scm metadata to fill in versions in package metatata and if requested python files, unfortunately poetry cant yet support its integration, and flit never will
[08:40:09] <famubu> ronny: Is flit meant for simpler projects or something? Docs says "if your package needs a build setup, you won't be able to use flit". I guess I'm not experienced enough to understand what that means...
[08:40:44] <McSinyx[m]> famubu: build setup refers to extension modules I think
[08:41:46] <McSinyx[m]> i.e. modules need to be compiled from c/c++/fortran/ect.
[08:42:18] <famubu> McSinyx[m]: Oh... I understand now.
[08:42:20] <McSinyx[m]> ronnypfannschmidt: could you please elaborate why flit will *never* imply version from SCM?
[08:43:43] <McSinyx[m]> oops I found it now, sorry for asking something that can be easily searched: https://github.com/takluyver/flit/pull/199#issuecomment-415677849
[13:36:09] <ronny> McSinyx: author rejected proposed integrations, i wont try again
[13:37:03] <McSinyx[m]> I found the discussion, thank you though
[13:52:38] <ngoldbaum> that’s interesting, licenses aren’t included because of the *bandwidth implications*
[13:53:00] <ngoldbaum> work on things used enough to worry about stuff like that
[15:43:57] <McSinyx[m]> PyDon: I think I said this before, pip does not vendor wheel
[15:44:39] <McSinyx[m]> I can recall an issue where this is discussed, but vendor wheel are terrible keywords to look up d-:
[15:45:23] <PyDon> Hehe, true. I understand, my intention was also just for my clarification and implications, not to raise or make an issue out of it. If you think thats the best, please feel free!
[15:45:46] <PyDon> Personally I was just trying to make sense out of it what that means for me if I ship pip with my embedded Python env.
[15:47:01] <McSinyx[m]> I hope it is clear to you now, and IMHO there's no legal issue if you do it
[15:47:12] <PyDon> Absolutely! Thank you for the clarification!
[15:47:27] <McSinyx[m]> (but if the police knocks your door don't quote me on that)
[15:48:01] <ngoldbaum> no one expects the spanish inquisition
[15:49:21] <PyDon> Lol! But McSinyx, a guy I know from the internet, said..