Re: [Distutils] Last PEP 426 update for a while
On 3 Aug 2013 06:01, "PJ Eby" wrote: > > On Fri, Aug 2, 2013 at 11:27 AM, Nick Coghlan wrote: > > I pushed a version of PEP 426 with an initial sketch of an entry > > points replacement design: http://hg.python.org/peps/rev/ea3d93e40e02 > > > > To give it a sensible home in the PEP, I ended up defining "modules" > > and "namespaces" fields in addition to "commands" and "exports". The > > overall section is called "Installed interfaces". > > > > I initially tried it with the unpacked multi-field mapping for export > > specifiers, but ended up reverting to something closer to the > > setuptools notation for readability purposes. For the moment, > > "requires_extra" is included since it isn't that hard to explain. > > Thanks again for all the hard work in putting this together! > > Btw, under setuptools, entry point *group* names are restricted to > valid Python module names, so this is a subset of valid distribution > names. Conversely, entry *point* names are intentionally arbitrary > and may contain anything that isn't an '=', as long as they don't > start with a '#'. > > The reason for these choices is that entry point groups are used to > ensure global uniqueness, but need a standard way for subdividing > namespaces. (Notice that setuptools has groups like > distutils.setup_arguments and distutils.setup_commands.) > > Conversely, individual entry point names have a free-form syntax so > that they can carry additional structured information, like a > converter specifying what it converts from and to, with a quality > metric. The idea is to allow tools to build plugin registries from > this kind of information without needing to import the modules. > Basically, if you can fit it on one line, before the '=', in a > reasonably human-readable way, and it saves you from having to import > the module in order to figure out whether you wanted to import it in > the first place, you can put it in the name. > > You might wish to make names a bit more restrictive than this, I > suppose, but I'm not sure that all of the limitations of distribution > names are actually appropriate here. In particular, restricting to > alphanumerics, dots, and dashes is *way* too restrictive. Entry point > names are sometimes used for human-readable command descriptions, e.g. > this is a perfectly valid entry point definition in setuptools: > > wikiup: Upload documents to one or more wiki pages = > some.module:entrypoint [extra1, extra2] > > Anyway, entry point group names are definitely *not* recommended to > follow distribution names, as that makes them rather useless. Things > that consume entry points will generally have more than one group, > eventually, so at least one of those groups will then have to *not* be > named after a distribution, unless you arbitrarily break up the > project into multiple distributions so the group names match, which is > kind of silly. ;-) This makes sense - I was trying to cut down on the number of different naming schemes we had, but may not have divided things up well. How about we go with: Valid dotted names for: - modules - namespaces - module & name portions of export specifiers - export group names - extension names Valid distribution names for: - script wrappers Arbitrary strings for export group entries. > > Finally, it might be good to point out once again that extras are not > so much "a set of dependencies that will be checked for at runtime" as > a set of dependencies that are *needed* at runtime. This need may or > may not be checked, and may or may not be satisfied dynamically at > runtime; it depends on the API in use, and how/whether it is invoked. An unconditional import of an optional dependency counts as a runtime check in my view :) Agreed that could be clarified in the PEP, though. Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Monthly Download Counts on PyPI
Donald Stufft stufft.io> writes: > > Just a quick update that the monthly rolling download counts are now enabled on PyPI which means the download count rollout is now complete. \o/ Thanks ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] a plea for backward-compatibility / smooth transitions
On Aug 2, 2013, at 4:28 PM, PJ Eby wrote: > I also want to just throw in one extra piece of information for you > and anybody else reading this: 99% of "stop energy" doesn't happen > because people actively want to prevent progress or frustrate other > people. It simply happens when people notice a problem but don't have > as much personal stake in your goal as they do in not experiencing the > problem they will experience (or perceive they will), from the > proposed change. One of the biggest things I viewed as stop energy was how impossible it seemed to get a SSL certificate that was trusted in most major browsers to be used on PyPI. There was never any reason given that we couldn't move to one, just simply "we already have a certificate" without addressing the reasons I was trying to get a different one. Beyond that it was other random proposals that it felt like people put in the minimal amount of effort in order to find a reason to say no to it. Then if I addressed that particular concern, they'd again seem to put in the minimal amount of effort to find a reason to say no. It felt like the goal posts were just constantly being moved to slightly further away each time. That sort of behavior is mostly what I mean by "stop energy". It's entirely frustrating and it feels like it's entire purpose is to dissuade someone from changing the status quo, wether that was the intention or not. Everything else you said has been noted :) - 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] a plea for backward-compatibility / smooth transitions
On Tue, Jul 30, 2013 at 4:58 PM, Donald Stufft wrote: > Hrm. > > So I hear what you're saying and part of the problem is likely due to the > history > of where I tried to get a change through and then felt like all I was getting > was > stop energy and people wanting to keep the status quo which ultimately > ended up preventing changes has lead me to view distutils-sig in more of an > adversarial light then is probably appropriate for the distutils-sig of 2013 > (versus > the distutils-sig of 2011/2012). This is probably reflected in my tone and > likely > has others, such as yourself, respond similarly, pushing us further down that > path. My thought process has become "Ok here's something that needs to > happen, now how do I get distutils-sig not to prevent it from happening". Thanks for the thoughtful response. I appreciate it. I also want to just throw in one extra piece of information for you and anybody else reading this: 99% of "stop energy" doesn't happen because people actively want to prevent progress or frustrate other people. It simply happens when people notice a problem but don't have as much personal stake in your goal as they do in not experiencing the problem they will experience (or perceive they will), from the proposed change. When you look at it from this perspective, it's easier to understand that the way to fix this is with more engagement on their part, which can only be gotten by engagement on your part. When I first proposed WSGI, the initial reaction of Web-SIG was pretty negative. "Stop energy" if you will. Things only moved forward once I was able to channel the energy of objections into offering solutions. It's helpful to remember that asking, "okay, so how you would recommend I do it?" *doesn't* obligate you to actually follow all of the recommendations you get. (Especially since some of them will be mutually contradictory!) Anyway, I guess what I'm saying is that people lacking enthusiasm for your goals is not really them trying to stop you. In fact, objections are a positive thing: it means you got somebody's attention. The next step is to leverage that attention into actually getting help, or at least more constructive input. ;-) It's true that some individuals will never provide really helpful input. In the WSGI effort, there were people whose advice I never took, because their goals were directed entirely opposite to where I wanted to go. But I remained engaged until it was mutually clear (or at least I thought it was) that our goals were different, and didn't try to persuade them to go in the same direction. Such attempts at persuasion are pretty much a waste of time, and a big energy drain. Consensus-building is something that you do with people who have at least some goals in common, so it's best to focus on finding out what you *do* agree on. > This was again reflected in the Python 2.3 discussion because my immediate > reaction and impression was that you were attempting to block the move > from MD5 due to Python 2.3, which I felt 2.3 wasn't worth blocking > enhancements > to PyPI. The "snark" in my statements primarily came from that feeling of > someone was trying to "shut down" an enhancement. Right. In such a case, a question you could ask is, "Do you agree in general that we should move to a better hash at some point in the future?", because then the disagreement can be narrowed down to timeframe, migration or deprecation process, etc. The truth is, I had no intention of "blocking the move", I had concerns I wanted addressed about the impact, timing and process. (Actually, I originally just noticed a couple of errors in what you'd laid out as the current state of things, and wanted to make sure they were included in the assessment.) The point is, if somebody doesn't have *any* common ground with you, it's unlikely they're even talking to you. At the very least, if they're talking with you about PyPI, they must care about PyPI, even if they care about different things than you, or with different relative priorities. ;-) > As far as how to fix it I don't have a particularly magic answer. I will try > to be more > mindful of my tone and that distutils-sig is likely not my adversary anymore > as well > as try to ask questions instead of arguing the relevance immediately. Again, thank you. And hopefully, remember that probably nobody was intentionally being your adversary before, either. As the old adage says, the best way to destroy your enemies is to make friends with them. ;-) And we do that by focusing on common ground, and inviting participation. (This is again not to say that I've been 100% Mr. Wonderful myself; I know I haven't. But the community's best consensus-building happens when somebody is doing the tough work of engaging with all parties. Sometimes this doesn't happen, alas; back when I was developing setuptools there just weren't enough people interested in the problems available on Distutils-SIG to build a
Re: [Distutils] Last PEP 426 update for a while
On Fri, Aug 2, 2013 at 11:27 AM, Nick Coghlan wrote: > I pushed a version of PEP 426 with an initial sketch of an entry > points replacement design: http://hg.python.org/peps/rev/ea3d93e40e02 > > To give it a sensible home in the PEP, I ended up defining "modules" > and "namespaces" fields in addition to "commands" and "exports". The > overall section is called "Installed interfaces". > > I initially tried it with the unpacked multi-field mapping for export > specifiers, but ended up reverting to something closer to the > setuptools notation for readability purposes. For the moment, > "requires_extra" is included since it isn't that hard to explain. Thanks again for all the hard work in putting this together! Btw, under setuptools, entry point *group* names are restricted to valid Python module names, so this is a subset of valid distribution names. Conversely, entry *point* names are intentionally arbitrary and may contain anything that isn't an '=', as long as they don't start with a '#'. The reason for these choices is that entry point groups are used to ensure global uniqueness, but need a standard way for subdividing namespaces. (Notice that setuptools has groups like distutils.setup_arguments and distutils.setup_commands.) Conversely, individual entry point names have a free-form syntax so that they can carry additional structured information, like a converter specifying what it converts from and to, with a quality metric. The idea is to allow tools to build plugin registries from this kind of information without needing to import the modules. Basically, if you can fit it on one line, before the '=', in a reasonably human-readable way, and it saves you from having to import the module in order to figure out whether you wanted to import it in the first place, you can put it in the name. You might wish to make names a bit more restrictive than this, I suppose, but I'm not sure that all of the limitations of distribution names are actually appropriate here. In particular, restricting to alphanumerics, dots, and dashes is *way* too restrictive. Entry point names are sometimes used for human-readable command descriptions, e.g. this is a perfectly valid entry point definition in setuptools: wikiup: Upload documents to one or more wiki pages = some.module:entrypoint [extra1, extra2] Anyway, entry point group names are definitely *not* recommended to follow distribution names, as that makes them rather useless. Things that consume entry points will generally have more than one group, eventually, so at least one of those groups will then have to *not* be named after a distribution, unless you arbitrarily break up the project into multiple distributions so the group names match, which is kind of silly. ;-) Finally, it might be good to point out once again that extras are not so much "a set of dependencies that will be checked for at runtime" as a set of dependencies that are *needed* at runtime. This need may or may not be checked, and may or may not be satisfied dynamically at runtime; it depends on the API in use, and how/whether it is invoked. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Monthly Download Counts on PyPI
Just a quick update that the monthly rolling download counts are now enabled on PyPI which means the download count rollout is now complete. - 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
[Distutils] Last PEP 426 update for a while
I pushed a version of PEP 426 with an initial sketch of an entry points replacement design: http://hg.python.org/peps/rev/ea3d93e40e02 To give it a sensible home in the PEP, I ended up defining "modules" and "namespaces" fields in addition to "commands" and "exports". The overall section is called "Installed interfaces". I initially tried it with the unpacked multi-field mapping for export specifiers, but ended up reverting to something closer to the setuptools notation for readability purposes. For the moment, "requires_extra" is included since it isn't that hard to explain. The other two major additions to the PEP are a note near the top explaining that the expected time frame for metadata 2.0 is post Python 3.4 release and a caveat on the build system description explaining that we know it isn't ready for prime-time yet. I wanted to get this part up so anyone tinkering with wrapper scripts had at least a preliminary scheme to work from, but as per the note on time frames, I don't consider the details of PEP 426 to be an urgent topic for further discussion unless/until it directly impacts next generation tools like Warehouse and distlib. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] How to disable PYTHONPATH checking when installing packages using distribute
Hi, During installing a package which uses distribute (matplotlib in this case), it refuses to work with this message "running install Checking .pth file support in /usr/local/stow/matplotlib-1.3.0/lib/python2.7/site-packages/ /usr/bin/python -E -c pass TEST FAILED: /usr/local/stow/matplotlib-1.3.0/lib/python2.7/site-packages/ does NOT support .pth files error: bad install directory or PYTHONPATH ... Please make the appropriate changes for your system and try again." I install local packages using the stow approach, which installs each package under its own sub-directory and later "stowed" (https://www.gnu.org/software/stow/). Such "error" becomes a nuisance as a different PYTHONPATH has to be set for each installation of a package. How can the checking be disable? I don't seem to be able to find anything in the documentation and would be grateful for any pointer. Or maybe it's better turned into a warning and users be reminded to add the install directory to PYTHONPATH. Regards, ST -- ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
