Re: [Catalog-sig] Merge catalog-sig and distutils-sig
+1 ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] V3 PEP-draft for transitioning to pypi-hosting of release files
In addition, maintainers of installation tools are asked to release two updates. The first one shall provide clear warnings [...] The second update for installation tools should change the default mode to allow only installation of package files hosted at the index domain, sounds good to me. It is expected that tools in this release may choose to change the default index url to ``https://pypi.python.org/simple/-with-ext``https://pypi.python.org/simple/-with-extin so, *eventually*, the /simple interface (that has been transitioned to only serve pypi links) could be deprecated? (because new tools would be smart enough to responsibly navigate /simple/-with-ext) but slightly ironic that we'd be left with an interface called simple/-with-ext, given the goal of all this, but it makes sense. Marcus ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Deprecate External Links
pip/easy_install into installing the right thing by version number naming (which is completely broken btw. It's impossible to name separate Python 2 and Python 3 packages so that both pip and easy_install will do the right thing in every case. See https://code.google.com/p/sympy/issues/detail?id=3511). to be clear, in this issue, easy_install is broke, but i understand you want something that works consistently across both tools. Marcus ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Deprecate External Links
As far as I'm concerned, pip is broke too, in the sense that the method we use to make pip work in Python 3 is a bit of an annoying hack (namely, upload a separate tarball for each minor Python 3 version). I agree it's a hack. but only =1.2 package metadata supports requires-python and nothing is writing that now (except for wheel). if newer metadata were pervasive and available on pypi, pip could respond to it. I think it would probably automatically start showing up in the json and xml interfaces? but would require some changes to expose an html attribute for the simple interface, which pip currently uses. Marcus ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Deprecate External Links
maintainers. The way pip works now, every time I do a release candidate, pip automatically installs it, even though I only upload it an option to exclude pre-releases (or in reverse, an option to allow them) does seem overdue. reasons not to do this? anyone? links to the most relevant conversations/posts from the past? well), but rather, just set the classifier for the download like you were supposed to in the first place, and it will just work. With this change if I (the package maintainer) do the right thing, pip does the right thing. The way it is now, if I do the right thing, pip does the wrong thing it's not clear that trove classifiers is the consensus on how an installer should know about the python version. surfacing requires-python in pypi for installers (when metadata-version =1.2 actually becomes pervasive) seems like the right idea. but maybe an option to look at classifiers in the short term? not sure. Marcus ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Remove pypi redirects
fwiw, my company had build issues too for a moment. not pip, but distutils gathering a setup_requires dependency distutils.errors.DistutilsError: Download error for https://pypi.python.org/packages/source/s/setuptools_hg/setuptools_hg-0.4.tar.gz: [Errno 104] Connection reset by peer Marcus ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Remove pypi redirects
looking on the bright side, it made us aware that we had a leak to pypi in our build. we were trying to be local. so thanks. Had to go update our .pydistutils.cfg file Marcus On Tue, Feb 19, 2013 at 9:25 AM, Marcus Smith qwc...@gmail.com wrote: fwiw, my company had build issues too for a moment. not pip, but distutils gathering a setup_requires dependency distutils.errors.DistutilsError: Download error for https://pypi.python.org/packages/source/s/setuptools_hg/setuptools_hg-0.4.tar.gz: [Errno 104] Connection reset by peer Marcus ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] Remove pypi redirects
FYI, easy_install's --allow-hosts option can prevent such leaks. (But maybe that's why you're editing pydistutils.cfg ;-) ) btw, my edit was to override `index-url`. I want it to work locally. not just fail going remote. our mirror only has local links, but additionally adding something for `allow-hosts` sounds good too. Marcus ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
[Catalog-sig] http://cheeseshop.python.org/ returns 503
http://cheeseshop.python.org/ returning 503 seems to be new since the cert change? Is this intentional? trying to sort out a few pip test failures. there's an older test getting links from here http://download.zope.org/ppix/INITools/ which has cheeseshop urls. Marcus ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
Re: [Catalog-sig] PyPI and setuptools
This is an option: https://gist.github.com/zed/1347055 btw, this is similar to what pip is doing in it's pull https://github.com/pypa/pip/pull/791 although, the example given at the top of the gist just *adds* this handler using urllib2.build_opener. the pip pull is going a little further and explicitly removes the bare HTTPHandler from the call chain, otherwise the HTTP handler is in the *front* of the call chain, and there was the concern (which should be confirmed with testing), that it might get called during a MITM spoof. Marcus ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
[Catalog-sig] Use user-specific site-packages by default?
Hello, another pip maintainer here (I think that's 4 of us in here now that I know of). I just joined this list, so couldn't respond to the original email, so just pasted it below. I haven't read all the way though all the messages, so apologize for redundancies. This all sounds reasonable to me, and pip did improve the --user support a lot in v1.2.1, so that's good timing. There's still a few --user bugs to be fixed, but all very doable, if its really meant to play such a major role like this. I admit though, I had to do a double take on this thread. For many users, virtualenvs are their user install, and sudo global installs are pretty rare. So, putting in a lot of work to fix what to many seems like a rare behavior makes me a little hesitant. But many users isn't all I guess, and maybe I'm off on the many part, not sure. I guess it's still worthwhile to prevent *any* unnecessary root installs. Maybe user education is enough? I was going to add a section to pip's new cookbook on --user installs, and with all the focus on security now, it could be emphasized really strongly and explained why it's a good thing. This, along with adding informative messages when users fail writing to the global site might go a long way. Btw, the user site is visible in virtualenvs that have global access (and is lower in precedence than the virtualenv site-packages), so I'm pretty sure it can serve as a place for common packages, that the global site is often used for. Marcus Inside a virtual environment: pip install pkg: works as now pip uninstall pkg: works as now Ordinary user (no write-access to system site packages): pip install pkg: installs to per-user site packages pip uninstall pkg: uninstalls from per-user site packages pip install --user pkg: installs to per-user site packages pip uninstall --user pkg: uninstalls from per-user site packages pip install --system pkg: fails (likely with a permissions error) pip uninstall --system pkg: fails, even if the package is present (likely with a permissions error) Administrator/root (write-access to system site packages): pip install pkg: asks for confirmation before installing to per-user site packages pip uninstall pkg: asks for confirmation before uninstalling from per-user site packages pip install --user pkg: installs to per-user site packages pip uninstall --user pkg: uninstalls from per-user site packages pip install --system pkg: install to system site packages pip uninstall --system pkg: uninstalls from site packages ___ Catalog-SIG mailing list Catalog-SIG@python.org http://mail.python.org/mailman/listinfo/catalog-sig
