PMXBOT Log file Viewer

server donated by Rackspace

Help | Karma | Search:

#pypa logs for Thursday the 4th of September, 2014

(Back to #pypa overview) (Back to channel listing) (Animate logs)
[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