Mailman 3 June 2010 - Distutils-SIG

stdeb followup
by Barry Warsaw 19 Jun '10

19 Jun '10

Hi Andrew, I just wanted to follow up on stdeb and the debianize command you added. First of all, thanks! I've just pulled your git head and tried this out in a virtualenv, and it works exactly the way I'd hoped. Combined with some of the other things I'm working out[1] I think this is the way I intend to go. Kudos. I do have a few minor issues, and I'll file bugs on github for each. Also, I'm wondering if you've released a version with the debianize command, and if not when you might do that. I'd like to work on getting that available in Debian, Ubuntu, and my PPA. Cheers, -Barry [1] http://www.wefearchange.org/2010/05/from-python-package-to-ubuntu-package.h…

2 2

Re: [Distutils] setuptools for py 2.7 windows
by P.J. Eby 18 Jun '10

18 Jun '10

At 08:35 AM 6/18/2010 +0100, Paul Moore wrote: >And of course, the irony is that "pure distutils" bdist_wininst >installers are not python version specific. It's setuptools itself >that modifies bdist_wininst to make the installers it builds python >version specific ;-) This is only the case for setuptools' *own* installer, because it installs different contents for different Python versions. Setuptools has some modules that are only used in Python 2.3, for example.

1 0

Re: [Distutils] setuptools for py 2.7 windows
by P.J. Eby 18 Jun '10

18 Jun '10

At 08:24 AM 6/18/2010 +0200, Lennart Regebro wrote: >On Tue, Jun 15, 2010 at 17:20, Adam GROSZER <agroszer(a)gmail.com> wrote: > > Hello, > > > > Someone please make a setuptools-0.6c11.win32-py2.7.exe. > >Just out of interest: Why are these versions needed? If you're asking why there are different .exe's for different Python versions, it's because currently, different modules and entry points are included, based on Python version. Distutils on Python 2.3, for example, does not include an 'upload' command, so setuptools provides one there. But on 2.4+, it is not necessary for setuptools to provide it, since it is already included. >Their isn't any >C-code in setuptools, doesn't the source version work just as well? There are .exe's so that Windows users don't have to do a lot of extra manual steps to get the installation process started, and so that they can uninstall via the Windows control panel.

1 0

Equivalent of config.h?
by Denis Jasselette 18 Jun '10

18 Jun '10

Hi, I use the GNU Autotools when I program in C. They generate a config.h file containing useful information such as the PACKAGE_VERSION that can be retrieved by simply including the file. I'd like to know if there exists anything similar with distutils. I am trying to distribute a script where I should be able to output the current version number. I thought that I could do things in an opposite way as in C. Rather than having the building system to create the config.h, I could import a config.py in my setup.py and distribute it as a py_module along with the script. Do you have better solutions?

4 11

setuptools for py 2.7 windows
by Adam GROSZER 18 Jun '10

18 Jun '10

Hello, Someone please make a setuptools-0.6c11.win32-py2.7.exe. -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: To do injustice is more disgraceful than to suffer it. - Plato

5 6

PyPI template improvements
by Simon de Vlieger 18 Jun '10

18 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey all, the recent activity on this mailinglist has kickstarted my contributing sense. As long as the mirroring debate is still ongoing I will focus my efforts somewhere else. Namely: the HTML/Javascript/CSS. In this regard I have a few questions before I really dig into these templates: - - Is there a list of improvements, maybe a nice TODO of points which people want to see improved? - - How are design changes handled, is there a committee to run them through? People who decide on what gets in and what not? (I'll outline some of my first thoughts lower in this mail) - - What are the supported browser versions by PyPI, I reckon it's IE6/7/8+, Fx 2+, Opera 9+ Safari 4+? The changes I have on my personal 'todo list' are: - - Add labels to all forms. - - Make tables consistent width (see for example the table in the top of the "Browse packages" page and compare with the table when you actually select one of the classifiers). - - Restyle the metadata display on package pages and move it up in the page. - - Have downloads readily available on the right side of the screen (at least the latest release). - - Look sternly at the top right floating account information page. - - Look at the your details page where the form does not align with the right floating profile box. - - Make one consistent styling for all forms. Include help texts in all forms. There are more things I want to do, but this is the start. I have already cloned Tarek's PyPI clone on Bitbucket and I'll add my changes there. Is there anything you guys (and the users) would really like to see improved? Regards, Simon de Vlieger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQIcBAEBAgAGBQJMGT6kAAoJEBBSHP7i+JXfHmsQALbm5rqRpLdjTDWNHLQHqoVE D4rDht/oaOFwPBfWp2FMRIhqLa9yA2AQfEAWSBFLqNMr2FGwpRPAXGgd38VOKOf0 pTORXM7cw92yjQXFz4J4xvcN7IcmyYEfftbwlITStnAEc5Q/5sl93nxyyigyQr7D y62EfCRGQP/OTfU7PYoj1KS9Qwi4ep6saD1cdL+tM7AgPiGwJMU2f29vElMVvT1G of+3gZjEi/UpsiYP/qD3JW3iFoOKv3KJbMmdHfMaPCa/vyfGRBoM4eGf5XvV+3oy U6EJ3YvvvTTS/w+TR36USxonuspYWKxoku1hUDaRsDgUC1fdW1UWVtocvnGzr1JW j06KN19ypzVK6UFoRTTsbA6K3h/pppgO1MIH9iAQgkvNY/irZiACO//x6bLT7ZFr 3PRt2ZaJzutKpUT0dGf0HjqcXdF6tPGnaQK1kkBGIgJrtXgqHqmc6Ee4S3Kd/boD tS9ZVqtIB2npJR4e0ZA6iqqGCNvpJlQEiUXSIpmTBRIgvpIjGcA/DQ+rQSIY8twS KPMGdnLm9u0HJdmlsRvJvH6/FBYIhoWDYWulil8ZpZnjHsyLAfTQjNeWzQDylEKF O750a9QgRIbeEFIOZK1kkaccy0dL3oX4MqJBfLlaJUlBJ0pYq3jTXf9+kc6g+uGc hutNfaPX84pe/oxL/z8k =hMyY -----END PGP SIGNATURE-----

3 5

Re: [Distutils] [Catalog-sig] Proposal: Move PyPI static data to the cloud for better availability
by Simon de Vlieger 15 Jun '10

15 Jun '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15 jun 2010, at 16:42, Mathieu Leduc-Hamel wrote: > I think the most important missed fact is, just how unreliable is PyPI > currently? Does anyone know? > > Exactly my point, right now, since the code is not completely clear > and not tested we don't really know what's supposed to worked and how. > > It's really a problem when the only way you have to know if > something goes wrong is when your users start complaining... Is there any Nagios monitoring in place or is there the need to have some external reliability monitoring in place? I can set up a Nagios machine to check the HTTP status of PyPi. Also, if the earlier described path of PyPi mirroring my the community is chosen I can happily have a server serving PyPi packages in the Netherlands. > > > I don't think this means what you seem to think it means. If you > replace > a single point of failure with N points of failure, your overall > reliability goes down, not up, since there are now more things to go > wrong. Assuming that they're independent points of failure, that means > your total number of failures will increase by a factor of N. > > > This is why we should work on the heart the problem problem, pypi > itself and why it's down sometime. > > Nobody know exactly what happen, maybe it's not a performance > problems. > > As you said, we may have the same problem in the future on all > mirroring nodes ... Yes, there should be some more investigative work be done on the reason of the apparent unreliability. Regards, Simon de Vlieger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQIcBAEBAgAGBQJMF5YCAAoJEBBSHP7i+JXfGysP/0IKUsf0KTvjrXn50RvrH2gp jwIpkVfmzbXNGx2EfSywDFNv9neyKqDF844kR2+Vsr96jFnA0EQyUW3nGy7G9q0q bOc2e2GxCauYXDJoGdxGs1S1aS+1z2oyNd2qYZdFDJM236JnKSLHlA3r383cAfDJ bL46SRDeq19IEgOuwjAU9z74+y7t95tomlYX+DgcB4n7cuePCFTym4nWoavjPyE5 4JLN0+Oo6jBf5FwE4WH3e1HWdrbDck7LJTMltB1W2ex6DUPTW9u+tfpc0Bd8DDjP LPcZN2smyqJEFRI89VmLMvwh91wYhAWqGnm42FmgLaKha06SsxxO8b28SSSywYca TZcv+72d59mZSDkF94DtD9CY0Q0feMKN2+O5d3JA8OTb7QosCUNSH8FGE0A3dOk9 jDVlHoQSqYv4FDHrQbLy8pG6A8z9nJK+8Gk3b55mKcfTIFAcYs94WYprY1ZrO42r YLwwF1ngQ9LUuQcJ+7XFpzS/DbNPmXdo5QJuI48usjZrdh6Dub0N0ruaqxWRNOh6 lYz2djbUgUd5xRjG43b0MemRbyiWbb2eZBnvj2+aoCVNXE6xxBpUzzA7FoQvKfSa mF+i//1xKNRxw9ms7WVMDL+FzIxjRrVyEpW0MDKwB3sWkMjjQh8ag2aqIMr6vWKY djCUFH87ofhC+oIIu8Lh =1sDK -----END PGP SIGNATURE-----

2 1

Re: [Distutils] Design rationale for the egg format ?
by P.J. Eby 15 Jun '10

15 Jun '10

At 01:25 PM 6/15/2010 +0900, David Cournapeau wrote: >On Tue, Jun 15, 2010 at 10:36 AM, P.J. Eby <pje(a)telecommunity.com> wrote: > > > As I said above, "it *also* scales better for performance" -- i.e., it's a > > secondary concern. > >ok. > > > Â The #1 reason for separating metadata files is that it > > makes the addition of new metadata much easier than maintaining a single > > monolithic format. > >Do you still think it is true today ? I am asking because AFAIK, there >aren't many packages besides setuptools which use those metadata ? That depends on what you mean "besides setuptools". Entry points, for example, are used by various apps and frameworks that implement plugins, and these in turn are used by app and plugin developers. There's also a package (EggTranslations I think?) that uses metadata files for i18n discovery, allowing plugins to provide translations for an app, or translations for other plugins. So, it's true that it's not very common that a library or app would directly use metadata files -- in general, you'll go through an intermediary such as setuptools or EggTranslations... or even a third level, such as an app framework that then uses setuptools internally to implement a plugin API. >I >don't mean to criticize the design, just to see if you would do things >differently today. Oh, many things. But separating metadata files is definitely NOT one of them. As you might notice, PEP 376 and Distutils2 build even further on this pattern, with roughly the same rationale(s).

2 1

Re: [Distutils] Is it safe to embedding additional metadata in bdist_wininst installers ?
by P.J. Eby 15 Jun '10

15 Jun '10

At 02:51 PM 6/15/2010 +0900, David Cournapeau wrote: >I am interested in doing this for arbitrary packages (the goal is to >add support for egg <-> windows installer conversion in my packaging solution) If your goal is to convert between eggs and bdist_wininst installers, you might want to take a look at the code that already exists in easy_install to convert bdist_wininst .exe files to .egg files -- even ones that weren't built by setuptools. Converting the other way should also be similarly straightforward, so I'm curious what this other metadata is that you're asking about.

1 0

Is it safe to embedding additional metadata in bdist_wininst installers ?
by David Cournapeau 15 Jun '10

15 Jun '10

Hi, I am interested in adding some metadata in the installers generated by bdist_wininst. I did it through a hack: base64-encoding the medata in a new section in the embedded cfgdata. From my understanding the installer.c sources, this seems safe, and the generated installer does work, but I am wondering whether there is a better way of doing it, and whether it could potentially breaks something, cheers, David

2 5