new port: python/py-scard 1.6.12

[schmurtz_macport@…]

Smart cards support to python

[ryandesign (Ryan Carsten Schmidt)]

Thanks. Some remarks:

• "categories python" should be removed because the python portgroup sets that for you.
• The license field should indicate which version(s) of the LGPL apply. Not specifying the version means that all versions are acceptable, but the homepage says only versions 2.1 or later are acceptable, so the portfile should read "license LGPL-2.1+".
• master_sites should be written to avoid redirects.
• "python.default_version 27" should be removed because that's the default.
• There's some confusion in the end of the portfile. The "if {${name} ne ${subport}}" block should be the outer one, enclosing the declaration of the x11 variant and making it the default. We don't want the stub port to have any variants, and we don't want any ports to have variants that do nothing.
• I'm unclear on the purpose of the patch. But with or without it, the setup.py seems to hardcode -arch flags. We want ports to support the set of -arch flags the user requested, which are expressed in the variables ${configure.universal_archflags} (if the universal variant is selected) and ${configure.cc_archflags} (if it isn't). More simply, you can use the [get_canonical_archflags] procedure to get the correct -arch flags depending on whether the universal variant is selected or not. Even better, MacPorts already includes this information in the CFLAGS, CXXFLAGS and LDFLAGS environment variables; a properly-written setup.py should make use of those.

[ryandesign (Ryan Carsten Schmidt)]

Oh, and:

• "python.link_binaries_suffix" should be removed because it would cause the subports to conflict with one another and we don't want that.

[schmurtz_macport@…]

I've updated the Portfile.

For the setup.py script:

• the script automatically build for all the available architectures, so I shouldn't be a big issue (we may just build for more architectures than asked by the user).
• I don't want to rewrite the setup.py file in a way there's no real chance for the change to be accepted by upstream (that is with specific things linked to macport). The script is currently written so that it does not depend on a user configuration or port system, and managed well all cases.
• the patch I provided is just to take in account Mac OS X versions 10.7+ (and sent to upstream for integration). In the original version, specific cases were defined for 10.1-4 and 10.6, with a catch-other only relevant for 10.5; with the patch 10.5 is a specific case and catch-other apply for 10.6+.

Can we stay like that?

[neverpanic (Clemens Lang)]

I would have had a look at what you're proposing, but I've run into a few roadblocks:

• the port depends on py27-wxpython, but that's obsolete and replaced_by py27-wxpython-2.8; you should update the dependency. However,
• py27-wxpython-2.8 depends on wxgtk-2.8 and that doesn't correctly fetch for me.
• py27-scard -x11 tries to execute swig – do you need a build dependency on the swig-python port?

[neverpanic (Clemens Lang)]

Btw, always building universal will only be acceptable if that doesn't fail to link if any of the dependencies aren't installed +universal.

[petrrr]

Cc Me!