Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft don...@stufft.io wrote:
I like how Node.js packages handled this. The canonical form is {name:
Donald Stufft, email: don...@stufft.io, url:
http://github.com/dstufft/} (and what I think the internal representation
should be), but the tooling understands strings like Donald Stufft
don...@stufft.io (http://github.com/dstufft/). And both the email and url
data is optional.
How about the following as the canonical PEP 426 representation:
contact: {
name: Donald Stufft,
email: don...@stufft.io,
url: http://github.com/dstufft/;
}
contributors: [list of individual contact entries]
The point of the neutral contact entry is that it may be a larger entity like:
contact: {
name: Python Packaging Authority,
email: pypa-...@googlegroups.com,
url: http://github.com/pypa;
}
or the distutils-sig+BitBucket variant of that:
contact: {
name: Python Packaging Authority/Distutils SIG,
email: distutils-sig@python.org,
url: http://bitbucket.org/pypa;
}
As I work on the PEP 426 conversion to JSON as the on-disk format, I'm
also becoming convinced that we'll want at least a draft of the
replacement for PEP 390 (static input metadata) before I accept the
metadata 2.0 spec.
The key difference relative to PEP 390 is that the new PEP (for a
pymeta.cfg file) will be solely intended as an *input* format to a
build tool that populates pymeta.json when creating an sdist or wheel
file, whereas PEP 390 wanted to use the same format both for the
human-friendly input *and* as the machine readable interchange format.
Working on the PEP 426 conversion has confirmed my opinion that
splitting them is the right way to go, and also that a multi-file
input format is likely a better option than trying to cram everything
into one file.
Those two PEPs will then define this is where we want to get to
based on everything we've learned from the status quo and from looking
at other languages. Then the real work begins of figuring out how the
hell we can actually get there in a reasonable amount of time :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Apr 25, 2013, at 3:13 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Apr 25, 2013 at 1:54 PM, Donald Stufft don...@stufft.io wrote:
I like how Node.js packages handled this. The canonical form is {name:
Donald Stufft, email: don...@stufft.io, url:
http://github.com/dstufft/} (and what I think the internal representation
should be), but the tooling understands strings like Donald Stufft
don...@stufft.io (http://github.com/dstufft/). And both the email and url
data is optional.
How about the following as the canonical PEP 426 representation:
contact: {
name: Donald Stufft,
email: don...@stufft.io,
url: http://github.com/dstufft/;
}
contributors: [list of individual contact entries]
The point of the neutral contact entry is that it may be a larger entity
like:
contact: {
name: Python Packaging Authority,
email: pypa-...@googlegroups.com,
url: http://github.com/pypa;
}
or the distutils-sig+BitBucket variant of that:
contact: {
name: Python Packaging Authority/Distutils SIG,
email: distutils-sig@python.org,
url: http://bitbucket.org/pypa;
}
contact instead of author works for me. That's practically how it's implemented
in distutils ATM anyways (Maintainer overrides author and gets sent _as_ the
author).
As I work on the PEP 426 conversion to JSON as the on-disk format, I'm
also becoming convinced that we'll want at least a draft of the
replacement for PEP 390 (static input metadata) before I accept the
metadata 2.0 spec.
The key difference relative to PEP 390 is that the new PEP (for a
pymeta.cfg file) will be solely intended as an *input* format to a
build tool that populates pymeta.json when creating an sdist or wheel
file, whereas PEP 390 wanted to use the same format both for the
human-friendly input *and* as the machine readable interchange format.
Working on the PEP 426 conversion has confirmed my opinion that
splitting them is the right way to go, and also that a multi-file
input format is likely a better option than trying to cram everything
into one file.
I'm not sold on the pymeta.cfg file. Part of the purpose of defining the sdist
format instead of the tool that creates the sdist format is that we allow any
type of input file that someone wants to make a tool that does it. Further
more package creation should ideally be moved out of the stdlib and I don't see
much of a point to creating a PEP for a file that should never leave the
developers computer.
Those two PEPs will then define this is where we want to get to
based on everything we've learned from the status quo and from looking
at other languages. Then the real work begins of figuring out how the
hell we can actually get there in a reasonable amount of time :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
-
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] User Viewpoint: Packaging History, Confusion and User Advice
Thanks everybody for your feedback! On Wed, Apr 24, 2013 at 5:31 PM, Nick Coghlan ncogh...@gmail.com wrote: That's not a bad summary, and http://www.scotttorborg.com/python-packaging/index.html looks like an excellent resource. I'm going to write him an email pointing him to this thread. Maybe he's interested in giving the text to the Python community. As far as I could see it wasn't CC-BY-SA'd or something. We're currently trying to bring some order to the chaos, as described at http://python-notes.boredomandlaziness.org/en/latest/pep_ideas/core_packaging_api.html I love it! A good overview. It also clarifies general problems and requirements for a packaging ecosystem. I also like the approach of taking a step back and solving a problem that people faced, who tried to solve the obvious problem. This approach is often quite useful in problem solving. A lot of people can tackle the obvious parts of a problem set, but few people are able to find the core problems and present them in a human readable form. While reading I had the urge to convince you to go one more step back in hope of solving problems a lot of people will face in the next steps, which might not be obvious to you. As I understand correctly you already have a lot of experience in and around an RPM based packaging ecosystem. So you already know the architecture of a solution to a problem set that is quite close to what the python community has at the moment. This is not obvious to other people, though. I bet an analysis of existing and working packaging ecosystems would be really helpful in making plans. In the best case scenario it might be possible to find a Lego-like system of best practices which can be combined this way or another to weigh the pros and cons of each best practice. I think this might be a much better approach then making a plan out of what people guess might be a solution to existing problems. It's hard work, compared to the documents and overviews you are preparing now it might be even more inconvenient than writing those docs compared to programming. But the pay off might also be enormous. I think it's like writing PEPs something that doesn't result in working software directly but enables a lot of other people to write better code, which indirectly solves the coding challenge automatically. What do you guys think about that? Our current status is that most of the key projects are being gathered under the Python Packaging Authority banner on Github and BitBucket. I was already wondering what PyPA means. My essay linked above should eventually migrate to the meta-guide, and Scott's guide would be a useful link from the user guide (while it's desirable to have a default tutorial, linking to others can also be helpful for cases where the main guide doesn't make sense to users). Once the user guide and meta guide are in a better state, we'll update the stdlib distutils docs with a reference to them as a guide to a more up to date packaging toolchain. How can I get involved in that work? Both User Guide and Developer Hub didn't receive any commit this month, or I am not able to review the repositories well enough? I'm new to bitbucket and hg, so I have to ask: Is the current state of development checked in there somewhere? Also I don't see any Issues. Where are the current milestones (or footsteps) written down and the progress tracked? Regards, Erik ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pypa-dev mailing list
Okay, Gmane subscription requests sent with those names. If there's consensus to create the new list at some point, consider adding it to Gmane as well (I'll have forgotten by then, but it's good to make sure early messages are all archived). not sure about gmane naming, but my first reaction w/o knowing much would be like this: pip/virtualenv user list http://groups.google.com/group/python-virtualenv - gmane.comp.python.virtualenv pypa-dev list http://groups.google.com/group/pypa-dev - gmane.comp.python.pypa.dev as for whether pypa, or python in general, should have a generic packaging user list, that's come up, but no consensus as of yet, so no changes so far. (btw, the ideas that have been tossed around: packaging-user, pypa-user) so, I'm not sure about mapping python-virtualenv to pypa.user at the moment like you suggested. Marcus http://gmane.org/subscribe.php ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
Nick Coghlan ncoghlan at gmail.com writes: splitting them is the right way to go, and also that a multi-file input format is likely a better option than trying to cram everything into one file. There are areas of overlap, if you consider archiver, builder and installer roles. For example, the source files and in-package data are needed by both builder and archiver. The beauty of JSON is that it allows you to have your cake and eat it, to an extent. For example, if you consider that inputs to the different roles are dicts, it's not a big deal if you have a higher-level dict which contains the others as sub-dicts. So I don't see a big issue with having one file as long as the schema is clearly defined so that a specific role could pull out the relevant stuff. Also note that in the PEP 397 implementation (dictConfig) there is already the ability to have cross-references to shared sections in a dict serialised as JSON, so there's no need to compromise on DRY even when there are data overlaps. I've added some support for dict-based configuration in distlib (a backport of the generic configuration stuff from 2.7/3.2 dictConfig, to support 2.6) but the use of that's not yet documented. Regards, Vinay Sajip ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
I would prefer to see PEP 390 withdrawn and I think this has been suggested before. The metadata is already sourced from different files depending on your build system. The .ini format and our parsers for it are really awful. I always resented having to learn it in order to use distutils/setuptools when every other language (RFC822, Python, JSON) is both better and already familiar. FWIW bdist_wheel does something half-PEP-390 inspired with setup.cfg: [metadata] provides-extra = tool signatures faster-signatures requires-dist = distribute (= 0.6.34) argparse; python_version == '2.6' keyring; extra == 'signatures' dirspec; sys.platform != 'win32' and extra == 'signatures' ed25519ll; extra == 'faster-signatures' license-file = LICENSE.txt (https://bitbucket.org/dholth/wheel/src/tip/setup.cfg?at=default) On Thu, Apr 25, 2013 at 8:30 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Nick Coghlan ncoghlan at gmail.com writes: splitting them is the right way to go, and also that a multi-file input format is likely a better option than trying to cram everything into one file. There are areas of overlap, if you consider archiver, builder and installer roles. For example, the source files and in-package data are needed by both builder and archiver. The beauty of JSON is that it allows you to have your cake and eat it, to an extent. For example, if you consider that inputs to the different roles are dicts, it's not a big deal if you have a higher-level dict which contains the others as sub-dicts. So I don't see a big issue with having one file as long as the schema is clearly defined so that a specific role could pull out the relevant stuff. Also note that in the PEP 397 implementation (dictConfig) there is already the ability to have cross-references to shared sections in a dict serialised as JSON, so there's no need to compromise on DRY even when there are data overlaps. I've added some support for dict-based configuration in distlib (a backport of the generic configuration stuff from 2.7/3.2 dictConfig, to support 2.6) but the use of that's not yet documented. Regards, Vinay Sajip ___ 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] Simplify 426: Deprecate Author-email and Maintainer-email
On 25 Apr, 2013, at 15:58, Daniel Holth dho...@gmail.com wrote: I would prefer to see PEP 390 withdrawn and I think this has been suggested before. The metadata is already sourced from different files depending on your build system. I wouldn't mind a PEP 390 update when the 2.0 metadata format is done that limits it explicitly to distutils (and possibly setuptools), with the express purpose of making it possible to use a setup.cfg with a minimal setup.py file when using a new enough distutils version. In particular, a python distribution without extensions shouldn't require anything beyond this: from distutils.core import setup setup() This would make it easier to teach (GUI) tools, like IDLE, to maintain the input data used by distutils because they won't have to try to parse and update Python code. Using PEP 390 beyond distutils/setuptools isn't useful, there is no need to restrict other tools in this way as long as they can generate output in the right format (wheel and sdist archives). The .ini format and our parsers for it are really awful. I always resented having to learn it in order to use distutils/setuptools when every other language (RFC822, Python, JSON) is both better and already familiar. Funnily, I tend to use ini files a lot at $work because the are good enough for simple configuration and power-users/admins with a windows background are more likely to understand them then json or (shudder) xml files. FWIW bdist_wheel does something half-PEP-390 inspired with setup.cfg: [metadata] provides-extra = tool signatures faster-signatures requires-dist = distribute (= 0.6.34) argparse; python_version == '2.6' keyring; extra == 'signatures' dirspec; sys.platform != 'win32' and extra == 'signatures' ed25519ll; extra == 'faster-signatures' license-file = LICENSE.txt I use something simular in a number of my packages, with a single setup.py file shared between them and all metadata in setup.cfg. Ronald (https://bitbucket.org/dholth/wheel/src/tip/setup.cfg?at=default) On Thu, Apr 25, 2013 at 8:30 AM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Nick Coghlan ncoghlan at gmail.com writes: splitting them is the right way to go, and also that a multi-file input format is likely a better option than trying to cram everything into one file. There are areas of overlap, if you consider archiver, builder and installer roles. For example, the source files and in-package data are needed by both builder and archiver. The beauty of JSON is that it allows you to have your cake and eat it, to an extent. For example, if you consider that inputs to the different roles are dicts, it's not a big deal if you have a higher-level dict which contains the others as sub-dicts. So I don't see a big issue with having one file as long as the schema is clearly defined so that a specific role could pull out the relevant stuff. Also note that in the PEP 397 implementation (dictConfig) there is already the ability to have cross-references to shared sections in a dict serialised as JSON, so there's no need to compromise on DRY even when there are data overlaps. I've added some support for dict-based configuration in distlib (a backport of the generic configuration stuff from 2.7/3.2 dictConfig, to support 2.6) but the use of that's not yet documented. Regards, Vinay Sajip ___ 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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] HTTPS and certificate check update for distribute ?
The latest pip supports HTTPS URLs and certificate checks (according to the change log). Will there be a release of distribute that implements the same changes ? The current 0.6.36 still defaults to the HTTP PyPI address and doesn't do certificate checks. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Apr 25 2013) Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ 2013-04-17: Released eGenix mx Base 3.2.6 ... http://egenix.com/go43 : Try our mxODBC.Connect Python Database Interface for free ! :: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
I plan to reject PEP 390, since that feature won't be added to the stdlib. The reason we will need at least a minimal replacement for it is so that there's a standard place to define and retrieve the archiver hook that creates the sdist (and hence pymeta.json) from a source tarball or VCS checkout (as well as determine the necessary dependencies for that step). My reason for wanting to flesh out a more comprehensive pymeta.cfg spec, though, is as a sanity check on the proposed PEP 426 metadata. If I can't come up with a clean multi-file input format, then I will be highly suspicious of the underlying data model. Cheers, Nick. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Simplify 426: Deprecate Author-email and Maintainer-email
On Apr 25, 2013, at 10:47 AM, Nick Coghlan ncogh...@gmail.com wrote: I plan to reject PEP 390, since that feature won't be added to the stdlib. The reason we will need at least a minimal replacement for it is so that there's a standard place to define and retrieve the archiver hook that creates the sdist (and hence pymeta.json) from a source tarball or VCS checkout (as well as determine the necessary dependencies for that step). A minimal file that only requires what's needed for bootstrapping the archiver is fine. My reason for wanting to flesh out a more comprehensive pymeta.cfg spec, though, is as a sanity check on the proposed PEP 426 metadata. If I can't come up with a clean multi-file input format, then I will be highly suspicious of the underlying data model. I don't see anything wrong with making this spec but I don't think it should be conflated with the PEP for a standard way to bootstrap the archiver. I also don't think it belongs as a PEP as its not a proposal to enhance python just a test of the new metadata and an example of what an archiver _could_ use as its format. Cheers, Nick. ___ 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] HTTPS and certificate check update for distribute ?
On Thu, Apr 25, 2013 at 4:42 PM, M.-A. Lemburg m...@egenix.com wrote: The latest pip supports HTTPS URLs and certificate checks (according to the change log). Will there be a release of distribute that implements the same changes ? And FWIW, the same question would be relevant for buildout that depends on distribute now. -- Philippe Ombredanne +1 650 799 0949 | pombreda...@nexb.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Environment marker expression types
I was just fiddling with an experimental environment marker implementation for setuptools, and ran across a bit of a quirk in the spec. It says that the value of 'extra' is 'None', but that comparisons can only be done on strings. This leads to two problems: first, the syntax doesn't have a way to spell 'None', so you can't actually compare it to something. Second, if you compare it to a string using the equality operators, IIUC you'll get a TypeError under Python 3. Should it actually be defaulting 'extra' to an empty string? That would actually make a lot more sense, and avoid the issue of implementing non-string comparisons, None literals, etc. (Doing extras in this way actually has another problem, btw, which is that it's insane to do a != comparison on an 'extra'. And there are probably other insane operations on extras, because unlike everything else, the extra would need to be dynamically evaluated. I think it would probably be an improvement to remove extras from the environment marker system altogether and just have a mapping of extras instead, ala setuptools. But that can be treated as a separate issue from the 'None' problem.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Environment marker expression types
On Fri, Apr 26, 2013 at 10:12 AM, PJ Eby p...@telecommunity.com wrote:
I was just fiddling with an experimental environment marker
implementation for setuptools, and ran across a bit of a quirk in the
spec. It says that the value of 'extra' is 'None', but that
comparisons can only be done on strings.
This leads to two problems: first, the syntax doesn't have a way to
spell 'None', so you can't actually compare it to something.
It's not explained well in the current PEP, but there's an implied
extra is None if extra isn't mentioned in the environment marker (or
there's no environment marker at all)
Second,
if you compare it to a string using the equality operators, IIUC
you'll get a TypeError under Python 3.
Note that == and != don't emit TypeError with non-comparable types -
if both sides return NotImplemented from the corresponding magic
methods, then the comparison is just False for == and True for !=.
It's only the ordering comparisons that now emit TypeError rather than
attempting to guess an appropriate answer.
Should it actually be defaulting 'extra' to an empty string? That
would actually make a lot more sense, and avoid the issue of
implementing non-string comparisons, None literals, etc.
Once you account for the extras not mentioned implies extras is
None, the current system is at least self-consistent.
The main advantage of combining the systems is that it allows the
extras to *also* participate in the environment marker system (for
example, only adding certain dependencies if you're on Windows *and*
(Doing extras in this way actually has another problem, btw, which is
that it's insane to do a != comparison on an 'extra'. And there are
probably other insane operations on extras, because unlike everything
else, the extra would need to be dynamically evaluated. I think it
would probably be an improvement to remove extras from the environment
marker system altogether and just have a mapping of extras instead,
ala setuptools. But that can be treated as a separate issue from the
'None' problem.)
While working on the latest PEP 426 update, I've actually been
pondering the problem of how to handle the environment marker system
in general. Specifically, I *don't* really want anyone to need to
check any environment markers in the metadata passed to the
post-install hook, or even in the metadata recorded in the
installation database. The installer should be resolving all of those
at install time. However, then you get the interesting question of
what happens if you share an installation database across
heterogeneous machines via a network file system, implying that either
these things *have* to be evaluated at run time, solely in order to
accommodate that niche use case, or else we need to constrain that use
case by saying that it is up to the people setting it up to ensure
that the environments are *sufficiently* similar for things to keep
working.
Anyway, I have a draft design that I plan to use for the initial
rewrite, but it's one of the areas where I'll be most interested in
robust feedback:
1. All unconditional metadata goes in the top level fields
2. A new conditional top level field is added
3. The new field points to a mapping that uses environment markers as keys
4. Assuming that the only fields that participate in the environment
marker system are represented as lists (as is currently the case),
then the values in the conditional mapping will themselves be mappings
from field names to lists that describe the additional entries to be
appended to create the full list.
5. The installer evaluates the conditional metadata as appropriate
before writing the metadata out to the installation database and
invoking the post-install hook. Post-installation, the top level
metadata includes both the unconditional metadata *and* any
conditional metadata that applies to the current system.
For example, if the project metadata looked like this:
requires: [projectA, projectB]
conditional: {
sys.platform == 'win32': {
requires: [pywin32 (1.0)]
}
}
Then the installed metadata would be unchanged on Linux or Mac OS X,
but would look like this on Windows:
requires: [projectA, projectB, pywin32 (1.0)]
conditional: {
sys.platform == 'win32': {
requires: [pywin32 (1.0)]
}
}
This *does* mean I am inclined to split out the extras system as its
own top-level field that recapitulates this structure in miniature:
the extras fields would always remain separate from the top-level
ones, but could also include a set of conditional entries that were
evaluated and potentially added at install time:
extras : {
test : {
requires: [projectA, projectB]
conditional: {
sys.platform == 'win32': {
requires: [pywin32 (1.0)]
}
}
}
}
Anyway, this kind of problem is part of the reason the rewrite is
taking a
Re: [Distutils] Environment marker expression types
On Thu, Apr 25, 2013 at 8:12 PM, PJ Eby p...@telecommunity.com wrote:
I was just fiddling with an experimental environment marker
implementation for setuptools, and ran across a bit of a quirk in the
spec. It says that the value of 'extra' is 'None', but that
comparisons can only be done on strings.
This leads to two problems: first, the syntax doesn't have a way to
spell 'None', so you can't actually compare it to something. Second,
if you compare it to a string using the equality operators, IIUC
you'll get a TypeError under Python 3.
Should it actually be defaulting 'extra' to an empty string? That
would actually make a lot more sense, and avoid the issue of
implementing non-string comparisons, None literals, etc.
(Doing extras in this way actually has another problem, btw, which is
that it's insane to do a != comparison on an 'extra'. And there are
probably other insane operations on extras, because unlike everything
else, the extra would need to be dynamically evaluated. I think it
would probably be an improvement to remove extras from the environment
marker system altogether and just have a mapping of extras instead,
ala setuptools. But that can be treated as a separate issue from the
'None' problem.)
I wondered when someone was going to bring that up.
Markerlib, currently a part of distribute as _markerlib, works by
compiling each unique conditional (environment marker) to a function
using the AST module. One of the arguments to the function is extra
and the rest are the ordinary environment marker names like os and
python version.
(Markerlib also takes advantage of the fact that in AST/eval land
variable names can have dots in them without triggering attribute
access which I think is kindof cool.)
Once the marker is compiled it is really fast to evaluate a few times
which we do for extras (number of extras declared + 1 times). The way
they are evaluated / defined is designed to limit mischief like
installing different requirements if two extras are requested at once
instead of installing one extra, and then later installing the other.
It wouldn't make sense to write None in the environment marker
itself. We ask you not to mention extra at all in that case. Once
it's a function I can pass None as a parameter to guarantee it won't
match anything you wrote in your marker.
Long story short IMO the concrete requirements fall out more or less
effortlessly. I liked flattening the per-environment and per-extras
conditional requirements into a single mechanism, and I had no choice
pre-JSON-metadata.
Hello Nick!
It could also be more like
requires : [ { condition : foo == 'gurgle', requirements : [ bar,
baz ] } , { requirements : [ quux, splort ] } ]
for a conditional and unconditional requirement.
This syntax would also avoid putting data in keys which seems to be fashionable.
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Environment marker expression types
On Fri, Apr 26, 2013 at 11:56 AM, Daniel Holth dho...@gmail.com wrote:
requires : [ { condition : foo == 'gurgle', requirements : [ bar,
baz ] } , { requirements : [ quux, splort ] } ]
for a conditional and unconditional requirement.
This syntax would also avoid putting data in keys which seems to be
fashionable.
Good point, I realised conditional would be better as a list of
mappings with conditions as a field rather than a mapping with
conditions as keys:
requires: [projectA, projectB]
conditional: [
{
condition: sys.platform == 'win32',
requires: [pywin32 (1.0)]
}
]
I definitely prefer separating out the conditional data from the
unconditional data, though - keep in mind that this spec also defines
the runtime API for accessing this info as structured metadata.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
