Log file Viewer

[12:09:16] <gp> Does pip support findlinks over ftp/ftps? Or would I need to generate a findlinks html file from a directory list command?

[13:02:42] <ronny> gp: is there any valid reason for running a ftp service these days?

[13:14:13] <gp> because it is simple, built into the standard library, and i just want to store build files

[14:18:25] <ronny> gp: all the bad reasons :)

[16:59:06] <dstufft> gp: older versions of pip supported ftp, new versions don't

[17:02:10] <nanonyme> I'd expect pip to be able to cope with Apache automatically generated directory index out of a location that you push to over ftp

[17:02:41] <nanonyme> Just fwiw

[17:03:36] <nanonyme> Wow, I forgot to install Python on this machine :/

[17:07:26] <dstufft> yes pip will do that fine

[17:07:36] <dstufft> you can also use something like twisted if you want something pure python

[17:07:51] <dstufft> pip install twisted && twistd -n web --path /path/to/directory

[17:08:36] <nanonyme> Sure. It just may be less of a hassle convincing whoever owns the server to run Apache/nginx with directory indexes on it than Twisted

[17:08:51] <nanonyme> Also that typically comes with init scripts

[17:14:03] <nanonyme> dstufft, btw, considered that instead of vendoring requests the bootstrapping process would just install it?

[17:14:35] <dstufft> we don't want it installed, because if you uninstall it, or upgrade it to an incompat version, then your package manager is borked

[17:14:38] <tomprince> nanonyme: Then the version of requests you can use is tied to the version of pip you happen to have installed.

[17:15:05] <dstufft> vendoring means we don't assert anything about what dependencies you can have installed into your enviornment

[17:15:50] <nanonyme> Well. I guess. It's showing pretty bad example to Python projects on how to handle dependencies

[17:16:08] <dstufft> pip isn't your normal python project

[17:16:44] <dstufft> it's actually a class of problem that isn't really well solved

[17:16:50] <dstufft> I call them incidental dependencies

[17:16:58] <tomprince> The other option would be for pip to not live in the environment it is manipulating them.

[17:17:07] <tomprince> s/ them/

[17:17:15] <dstufft> like what if you use twine to upload your files, and twine depends on requests >= 2.4.0, but your project depends on requests < 2

[17:17:45] <dstufft> twine isn't a dependency of your project, the only reason you have it is to upload things, it's incidental to your environment

[17:17:54] <dstufft> tomprince: yea, pip used to support that, it didn't work very well

[17:21:36] <tomprince> Any particular reasons why not?

[17:22:43] <dstufft> mostly because pip and setuptools are very much designed to query the Python that is being ran against, it inspects the sys.path and things and there aren't a lot of good APIs for getting access to that information from outside it

[17:22:48] <tomprince> I guess it makes running setup.py trickier. And you depend on the python in the venv to supply you with paths to install to.

[17:23:18] <tomprince> Does venv address that?

[17:24:04] <dstufft> that could change in the future, with some effort. It's not clear it's a good idea either though, because it makes pip a wierdo in how you isolate it, since normally you install into a venv by activating it or by running the pip associated with that, instead we'd switch that so you'd have to have a CLI flag or something. IT's not a dead set against, just needs some thought to figure out if it's useful or not

[17:24:24] <dstufft> hm, venv might make some parts easier, but it's not a complete solution

[17:26:09] <tomprince> Well, the pip binary in the virtualenv could still be how you install in a venv, it just doesn't run from there. I'm not sure how that meshes with using python -m pip though.

[17:54:23] <gp> dstufft & nanonyme: thanks