Re: [Distutils] buildout bootstrap.py doesn't work on Sabayon Linux with system python
@Marius Gedminas @Ralf Schmitt Thanks for explanation and the tipp. Cheers Zoltan Benedek___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP449 - Removal of the PyPI Mirror Auto Discovery and Naming Scheme
Howdi, On 17. Aug2013, at 7:55 AM, Christian Theune wrote: > > Sorry for the stealth mode. The long thread has been sitting in my Inbox > while the last week was very busy and we're hosting a sprint at our offices > right now. > > I hope I will get around to reading and responding early next week. Well, almost. Picking the pieces back up, I'll stop bickering now [1]. I'm grateful for the offer to include gocept in a more formally trusted relationship. However, I don't think that adds more value and just defers paying back technical debt. I'll be a bit more aggressive with the migration and plan to do the following things: In the next days - Establish a new primary name for our mirror (probably pypi.rzob.gocept.net or something similar) - Inform our internal team that they should update f.pypi.python.org to the new name - Make f.pypi.python.org serve 301 redirects to the new name In two weeks: - Make f.pypi.python.org serve 401 Gone This should get your plan back on track. I'm happy with the proposal otherwise, thanks for taking the time to keep me informed! Christian PS: Not sure whether I missed anything important in the meantime … ;) [1] I still feel some need for personal interaction confirming or disproving some of my thoughts, but I don't think it's worthwhile to do that on a mailinglist. Personally I feel a bit stupid for the amount of pain we experience with the packaging right now - especially as we try to stay in touch and contribute. I don't mind the work in general but it would be nice to have less pain … ? -- Christian Theune · gocept gmbh & co. kg flyingcircus.io · operations as a service Forsterstraße 29 · 06112 Halle (Saale) · Tel +49 345 1229889-7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Multi-version import support for wheel files
On 28 Aug 2013 01:25, "Tres Seaver" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 08/27/2013 05:00 AM, Nick Coghlan wrote: > > > PJE and Jason were probably the only other current distutils-sig > > participants familiar enough with setuptools and pkg_resources to > > understand the distinction between that aspect, the default version > > handling and the activation API > > There are lots of folks here who have been building tooling on top of > eggs for almost a decade now. Perhaps those who *do* grok how that stuff > works (I'd be willing to guess a lot more than the three of you and > myself) weren't alarmed by you proposal. Oophobia is not ubiquitous. :) Ah, ye olde "Usenet nod" syndrome, the internet's ever-present friend skewing our perception of mailing list feedback :) Cheers, Nick. > > > > Tres. > - -- > === > Tres Seaver +1 540-429-0999 tsea...@palladion.com > Palladion Software "Excellence by Design"http://palladion.com > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlIcxDEACgkQ+gerLs4ltQ4qCgCfQKtjEAQkx7XnkQS8A8Q767E6 > lnwAoNJAcSDTbN6I1DW2DZAzC3lMvolQ > =AeYU > -END PGP SIGNATURE- > > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Multi-version import support for wheel files
On Tue, Aug 27, 2013 at 3:01 AM, Paul Moore wrote: > On 27 August 2013 00:15, PJ Eby wrote: > None of these things is wrong. It is *spreading* FUD (and in particular, > doing so cynically to undermine a proposal) that is wrong, and I hope I > didn't do that - I certainly did not intend to and I'm a bit unhappy about > the implication that I might have. Sorry for the implication; it was not intended. I did not think you had any intent to make other people share your doubts or had any desire to shoot down the proposal. As I said, the real intent of my (clearly, in retrospect, very poorly-worded) side-remark was that I thought 90% of the objections to Nick's proposals were based on fear, uncertainty, and doubt rather than any actual issues with the proposals themselves. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Multi-version import support for wheel files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/27/2013 05:00 AM, Nick Coghlan wrote: > PJE and Jason were probably the only other current distutils-sig > participants familiar enough with setuptools and pkg_resources to > understand the distinction between that aspect, the default version > handling and the activation API There are lots of folks here who have been building tooling on top of eggs for almost a decade now. Perhaps those who *do* grok how that stuff works (I'd be willing to guess a lot more than the three of you and myself) weren't alarmed by you proposal. Oophobia is not ubiquitous. :) Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlIcxDEACgkQ+gerLs4ltQ4qCgCfQKtjEAQkx7XnkQS8A8Q767E6 lnwAoNJAcSDTbN6I1DW2DZAzC3lMvolQ =AeYU -END PGP SIGNATURE- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Multi-version import support for wheel files
Nick Coghlan gmail.com> writes: > Just to scare people though... I did come up with a potentially decent > use case for .pth files: they're actually a reasonable solution for > sharing distributions between virtual environments in a way that works > cross platform and on all currently used Python versions. Say you want Right, and ISTM it also enables a useful subset of "setup.py develop" functionality where the .pth acts analogously to an .egg-link - the referenced project becomes importable while still being editable, though its headers, scripts and data are not installed, nor does it appear on a list of installed distributions. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP449 - Removal of the PyPI Mirror Auto Discovery and Naming Scheme
On Aug 27, 2013, at 7:10 AM, holger krekel wrote: > Being one of the people who wanted to but didn't feedback (still in vacation, > writing from a camping place with ssh/mutt and lousy connectivity FWIW): Ah! I hope you're having fun :) > > - the PEP claims that PEP381 mirroring protocol continues to exist. > But are the statements in > http://www.python.org/dev/peps/pep-0381/#statistics-page still valid, i.e. > does pypi.python.org still crawl mirrors for > statistics when the PEP449-DNS removal happens? Also PEP381 has > seen some modifications and enhancements before and after the CDN > introduction. PyPI hasn't crawled mirrors for statistics for 3 months? or so. Ever since download counts first got shut off and it has never been restored. Personally I have no plans to restore it. It caused needless complication and the download counts from the mirrors aren't that important IMO. The download counts are already inaccurate and are primarily useful as a form of relative comparison so the additional numbers do not aid much in the form of relativeness only in absolute counts (which as stated are already widely inaccurate). Perhaps PEP381 should be updates to take into account the new abilities added for mirrors that have happened recently (the Serials, the Headers etc). It also probably makes sense to update it since PyPI is no longer fetching statistics from the mirrors. I don't think we need a new mirror PEP though as the mirroring protocol is mostly the same and the enhancements exist primarily as a means of getting a more accurate mirror. I *do* have plans down the road to introduce a new mirroring protocol but that is a ways out still as there are other things higher up on my todo list. > > - relatedly, I'd suggest to clarify that this PEP does at least not preclude > further PEPs or attempts to introduce other means than DNS to manage > PyPI mirrors (one where mirror availability is stored at and queried via > a python.org address). Ideally, it should already incorporate a > procedure to register mirrors and to list them at a web page. I don't see this PEP as precluding anything else. Currently it points to http://pypi-mirrors.org/ as the place to locate new mirrors from in a manual fashion. I'm not too concerned with an automatic discovery protocol since the only installer as far as I'm aware that even used the existing one was pip which is removing that support in 1.5 anyways. That being said I'm not opposed to a new PEP introducing a different scheme but I probably won't be the architectof it and I can make a small update to it that it doesn't preclude further PEPs if that would make people feel more comfortable. > > - maybe a "future work" section could list these issues. > > I guess one underlying question is how much we want to rely on the CDN > mid/long-term. It's introduction was not discussed in a PEP but it > is mentioned e.g. in PEP449 as a reason to shutdown mirror management > infrastructure. Personally I see the CDN as the best option for the bulk of people wanting to install from a *public* mirror. There are of course situations where you might want to install from a different public mirror (China being a big one). I see mirrors mostly being useful for smaller use cases now. However I have no plans or desire to make the public mirrors go away other than the existing DNS names (and only then because of security concerns). > > That all being said, i am otherwise ok with PEP449 as DNS seems indeed > the wrong way to handle mirror management. Awesome good to hear. - Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA signature.asc Description: Message signed with OpenPGP using GPGMail ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP449 - Removal of the PyPI Mirror Auto Discovery and Naming Scheme
On Sat, Aug 24, 2013 at 16:47 -0400, Donald Stufft wrote: > On Aug 10, 2013, at 9:07 PM, Donald Stufft wrote: > > > [snip] > > > I guess I'm going to ask for some pronouncement on this? It's been two weeks > with no real feedback. > > FWIW tangentially related to this proposal, g.pypi.python.org is now 16 days > out of date. Being one of the people who wanted to but didn't feedback (still in vacation, writing from a camping place with ssh/mutt and lousy connectivity FWIW): - the PEP claims that PEP381 mirroring protocol continues to exist. But are the statements in http://www.python.org/dev/peps/pep-0381/#statistics-page still valid, i.e. does pypi.python.org still crawl mirrors for statistics when the PEP449-DNS removal happens? Also PEP381 has seen some modifications and enhancements before and after the CDN introduction. - relatedly, I'd suggest to clarify that this PEP does at least not preclude further PEPs or attempts to introduce other means than DNS to manage PyPI mirrors (one where mirror availability is stored at and queried via a python.org address). Ideally, it should already incorporate a procedure to register mirrors and to list them at a web page. - maybe a "future work" section could list these issues. I guess one underlying question is how much we want to rely on the CDN mid/long-term. It's introduction was not discussed in a PEP but it is mentioned e.g. in PEP449 as a reason to shutdown mirror management infrastructure. That all being said, i am otherwise ok with PEP449 as DNS seems indeed the wrong way to handle mirror management. best, holger > - > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA > > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Multi-version import support for wheel files
On 27 August 2013 10:00, Nick Coghlan wrote: > Just to scare people though... I did come up with a potentially decent > use case for .pth files: they're actually a reasonable solution for > sharing distributions between virtual environments in a way that works > cross platform and on all currently used Python versions. Say you want > to let virtual environments choose between "latest CherryPy 2" and > "latest Cherry Py 3". Install CherryPy2 into a directory called > "/full/path/to/some-alt-versions-directory/CherryPy2" and 3 into > "/full/path/to/some-alt-versions-directory/CherryPy3". > > Now you can say "use latest available CherryPy2" in your virtual > environment by adding a CherryPy2.pth file with a single line > containing: > > /full/path/to/some-alt-versions-directory/CherryPy2 > Personally, I have no particular objection to .pth files. What I dislike is: 1. A proliferation (well, two of them if you mean setuptools :-)) of general pth files containing multiple entries - I'd rather see the name of the pth file match the project it refers to, as you shown here. 2. The hacks in setuptools' pth files to put things near the *start* of sys.path. I know of no reason why this should be necessary. 3. Over-use of pth files resulting in an excessively long sys.path (less of a problem in 3.3 where scanning sys.path is a lot faster). The way pth files need to be on a "site" directory also causes some obscure and annoying failure modes in setuptools-based installs at times (nothing drastic, usually just a case of "you forgot to use --single-version-externally-managed again", so the pth issue is a symptom not a cause). So it's mostly that pth files have a bad rep because of the way they have been used in the past, rather than that they are a bad idea per se. I actually quite like this approach - it's simple and uses Python features that have been round for ages. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Multi-version import support for wheel files
On 27 August 2013 17:01, Paul Moore wrote: > On 27 August 2013 00:15, PJ Eby wrote: >> >> You pounced on a tiny piece of my email to Paul, in which I mainly >> expressed confusion about his statements about "cost". I was having >> trouble understanding what sort of "costs" he meant, and in subsequent >> discussion realized that it's because he and others appeared to have >> conflated setuptools' default-version issues, with Nick's proposal for >> handling non-default versions. > > > Note that I freely admit to *having* fear, uncertainty and doubt: > > I feared that Nick's proposal would impact users who just wanted to use > default versions. I was wrong, no issue, but I was concerned. > I was uncertain as to what Nick meant by "pkg_resources compatible". This > has now been explained, thanks, but I wasn't sure. > I doubted that I had the full picture and I was going to investigate. Others > provided extra information so I didn't need to do so myself, but I had > questions that needed to be answered initially. I think it was partly my fault, too. While I tried to emphasise that I was only interested in copying the pkg_resources back end layout for alternative versions in the initial post, the replies made me realise that (prior to this thread) PJE and Jason were probably the only other current distutils-sig participants familiar enough with setuptools and pkg_resources to understand the distinction between that aspect, the default version handling and the activation API (and my familiarity is a recent thing - I only really started understanding pkg_resources properly in the last couple of days while trying to fix a bug I reported a while back). While I haven't figured out how to fix the bug yet, I learned enough to figure out how to design a next generation alternative version mechanism that pkg_resources should be able to support, so I'm still calling that a win :) Just to scare people though... I did come up with a potentially decent use case for .pth files: they're actually a reasonable solution for sharing distributions between virtual environments in a way that works cross platform and on all currently used Python versions. Say you want to let virtual environments choose between "latest CherryPy 2" and "latest Cherry Py 3". Install CherryPy2 into a directory called "/full/path/to/some-alt-versions-directory/CherryPy2" and 3 into "/full/path/to/some-alt-versions-directory/CherryPy3". Now you can say "use latest available CherryPy2" in your virtual environment by adding a CherryPy2.pth file with a single line containing: /full/path/to/some-alt-versions-directory/CherryPy2 And similarly for CherryPy3.pth (but not in the same virtual environment as CherryPy2.pth!): /full/path/to/some-alt-versions-directory/CherryPy3 Because this actually modifies sys.path inside the environment, it works for both imports *and* for finding distribution metadata. If you upgrade the version of CherryPy2 or CherryPy3, all virtual environments referencing those directories will see the upgraded version. Anything using a version of CherryPy installed directly into the environment will ignore it. For those playing along at home... this is similar to how the default version support in setuptools works. The difference is that using .pth files to implicitly append to sys.path in a single-application virtual environment is significantly less surprising than doing so in a shared Python installation :) Cheers, Nick. P.S. If anyone missed me mentioning why I keep picking on the CherryPy 2 vs 3 migration, it's the actual parallel installation case that we have to deal with for beaker-project.org. Debugging some issues with that is what forced me to start learning how the multi-version support in pkg_resources actually works :) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Multi-version import support for wheel files
On 27 August 2013 00:15, PJ Eby wrote: > You pounced on a tiny piece of my email to Paul, in which I mainly > expressed confusion about his statements about "cost". I was having > trouble understanding what sort of "costs" he meant, and in subsequent > discussion realized that it's because he and others appeared to have > conflated setuptools' default-version issues, with Nick's proposal for > handling non-default versions. > Note that I freely admit to *having* fear, uncertainty and doubt: I feared that Nick's proposal would impact users who just wanted to use default versions. I was wrong, no issue, but I was concerned. I was uncertain as to what Nick meant by "pkg_resources compatible". This has now been explained, thanks, but I wasn't sure. I doubted that I had the full picture and I was going to investigate. Others provided extra information so I didn't need to do so myself, but I had questions that needed to be answered initially. None of these things is wrong. It is *spreading* FUD (and in particular, doing so cynically to undermine a proposal) that is wrong, and I hope I didn't do that - I certainly did not intend to and I'm a bit unhappy about the implication that I might have. (Not enough to make an issue of it, this is distutils-sig after all and you need a thick skin to hang out here :-)) Just as a side-note, I'm impressed by how careful everyone is being to keep discussions on distutils-sig friendly and constructive these days. My thanks to everyone for that. Paul ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
