Re: [Distutils] Proposal: moving PyPA projects to pydoctheme

[Ionel Cristian Mărieș via Distutils-SIG]

On Thu, Jun 1, 2017 at 1:06 AM, Jon Wayne Parrott <jonwa...@google.com>
wrote:

> I'm not seeing the sticky sidebar in the Python 3 docs?


H. It appears that sidebar.js is part of the sphinx base theme, not
sure what's going on in the python3 docs anymore ...​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Proposal: moving PyPA projects to pydoctheme

[Ionel Cristian Mărieș via Distutils-SIG]

Interestingly this doesn't have the "sticky" sidebar (eg: it moves as you
scroll page) as the py3 docs have. This is my attempt to package it into a
reusable theme btw:
http://ionelmc.github.io/sphinx-py3doc-enhanced-theme/bare/reference/foo.bar.html

You probably don't want to use that directly but maybe there is stuff you
can just copy from it.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Fri, May 26, 2017 at 7:32 PM, Jon Wayne Parrott via Distutils-SIG <
distutils-sig@python.org> wrote:

> Awesome, more good feedback. I've made some stylesheet adjustments to
> highlight both the current page (by bolding) and the current section (by
> coloring links). Let me know on the PR if you have alternative
> recommendations (leaving out the current section coloring is actually fine,
> IMO). Staged again here (http://temp.theadora.io/
> pypug-pydoctheme/self_hosted_repository.html).
>
> Since we mostly seem to all be in agreement, can someone who's an admin on
> the PyPA org create the pypa-theme repository for me?
>
> On Fri, May 26, 2017 at 5:13 AM Nick Coghlan <ncogh...@gmail.com> wrote:
>
>> Thanks for working on this, Jon!
>>
>> On 26 May 2017 at 17:06, Nathaniel Smith <n...@pobox.com> wrote:
>> > Further nitpick: the new version shows the whole ToC, but doesn't do
>> > anything to mark which part of it corresponds to the current page (cf
>> > the RTD theme's grey box), which makes it hard to orient oneself when
>> > looking at it. Some sort of "you are here" indicator would help :-)
>>
>> While the subtree expansion does provide a bit of that, I do agree
>> that some additional contrast between the expanded section and the
>> rest of the ToC would be beneficial.
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Outdated packages on pypi

[Ionel Cristian Mărieș via Distutils-SIG]

On Fri, Jul 15, 2016 at 1:51 AM, Steve Dower <steve.do...@python.org> wrote:

> This is why I listed a set of restrictions to help prevent that:
>
> * 140 chars (flexible, but short enough to prevent rants)
>

​Did you mean to write "provoke"​ instead of "prevent"? If we can learn one
thing from Twitter it's that such limit favors short and brutish comments
over the more nuanced and thoughtful ones - that take way more character
space of course.

I don't get what all this fuss is about about comments on PyPI. Such
feature seems unnecessary. There are plenty of ways to assess how well
maintained a package is. If a package maintainer wants comments or feedback
there's the url/long_description fields.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] package made up of only .so's?

[Ionel Cristian Mărieș via Distutils-SIG]

On Mon, Jul 4, 2016 at 6:53 PM, Chris Withers <ch...@simplistix.co.uk>
wrote:

>
> Each of these .so's is essentially a top level python module. How do I
> tell setuptools' setup() function to basically just roll these into a wheel?
>

​If you want to package arbitrary files take a look at this setup.py:
https://github.com/pytest-dev/pytest-cov/blob/master/setup.py
It should be simple enough to replicate, and it handles most ways to
install, besides wheels.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Docker, development, buildout, virtualenv, local/global install

[Ionel Cristian Mărieș via Distutils-SIG]

On Thu, Jun 16, 2016 at 3:29 AM, Donald Stufft <don...@stufft.io> wrote:

> Now you install a new version of setuptools that breaks the OS installed
> gyp and suddenly now you can’t build your static files anymore.


​gyp or node-gyp don't depend on python-setuptools, at least not on Ubuntu.
Are you referring to some concrete pkg_resources issue, assuming gyp uses
entrypoints api, and that api changed in some setuptools version? ​

​​On Thu, Jun 16, 2016 at 3:33 AM, Nathaniel Smith <n...@pobox.com> wrote:

> Using a virtualenv is cheap


Virtualenvs broke down on me and had mindboggling bugs one too many times
for me to consider them "cheap" to use. They make things weird (ever tried
to load debug symbols for a python from a virtualenv in gdb?)

I'm not saying they aren't useful.

​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Docker, development, buildout, virtualenv, local/global install

[Ionel Cristian Mărieș via Distutils-SIG]

On Thu, Jun 16, 2016 at 2:57 AM, Donald Stufft <don...@stufft.io> wrote:

> Of course It still applies to Docker. You still have an operating system
> inside that container and unless you install zero Python using packages
> from the system then all of that can still conflict with your own
> application’s dependencies.


​You're correct, theoretically. But in reality is best to not stick a dozen
services or apps in a single docker image. What's the point of using docker
if you're having a single container with everything in it? Eg: something
smells if you need to run a supervisor inside the container.

If we're talking about python packages managed by the os package manager
... there are very few situations where it makes sense to use them (eg:
pysvn is especially hard to build), but other than that? Plus it's easier
to cache some wheels than to cache some apt packages when building images,
way easier.
​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Docker, development, buildout, virtualenv, local/global install

[Ionel Cristian Mărieș via Distutils-SIG]

On Thu, Jun 16, 2016 at 1:52 AM, Reinout van Rees <rein...@vanrees.org>
wrote:

> Aaargh, that Gliph talk gave me a *lot* of food for thought. And that's a
> good thing.
>

​His main argument is that not using a virtualenv can lead to version
conflicts. Eg: app you installed with apt will probably break if it depends
on packages installed with pip. Not to mention the metadata and uninstall
mess that come with that.

A sound argument. However, none of that applies to a Docker image. You'd
have a single set of dependencies, so what's the point of using unnecessary
tools and abstractions. :-)​




Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Docker, development, buildout, virtualenv, local/global install

[Ionel Cristian Mărieș via Distutils-SIG]

On Wed, Jun 15, 2016 at 12:07 PM, Reinout van Rees <rein...@vanrees.org>
wrote:

> Now local development: it is normal to mount the current directory as
> /code/, so that now is overlayed over the originally-added-to-the-docker
> /code/.
>
> This means that anything done inside /code/ is effectively discarded in
> development. So a "bin/buildout" run has to be done again, because the
> bin/, parts/, eggs/ etc directories are gone.
>
​
Think of it like this: if you don't mount ./ as /code in the container then
you practically have to rebuild the image​ all the time. This is fine for
toy projects, but bigger ones have lots of files (eg: templates, images,
css, tons of js 1-line modules etc). That means you get a big context that
is slow to send (exacerbated in situations that have remote docker daemons
like osx/windows docker clients).

​Another compound problem: if you rebuild the image for every code change
the new context will invalidate the docker image cache - everything will be
slow, all the time. Ideally you'd have a stack of images, like a base image
that takes big context (with code/assets) + smaller images that build from
that but have very small contexts. I wrote some ideas about that here
<https://blog.ionelmc.ro/2016/05/07/dealing-with-docker/#optimizing-the-build-process>
if you have patience (it's a bit too long read).

Basically what I'm saying is that you got no choice but to mount stuff in a
development scenario :-)

Regarding the buildout problem, I suspect a src-layout can solve the
problem:

   - you only mount ./src inside container
   - you can happily run buildout inside the container (assuming it don't
   touch any of the code in src)

I suspect you don't need to run buildout for every code change so it's fine
if you stick that into the image building.

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to build python-packages depends on the output of other project

[Ionel Cristian Mărieș via Distutils-SIG]

On Fri, Jun 3, 2016 at 5:35 AM, Young Yang <afe.yo...@gmail.com> wrote:

> my_install is a subclass of `from setuptools.command.install import
> install`
> ```
> class my_install(install):
> def run(self):
> # DO something I want. Such as compiling the code of project A and
> copy the output of it (i.e. the .so file) to my binding folder
> install.run(self)
> ```
>
> At last I  add these options in my setup function in setup.py to include
> the shared library  in the install package.
> ```
>   package_dir={'my_binding_package': 'my_binding_folder'},
>   package_data={
>   'my_binding_package': ['Shared_lib.so'],
>   },
>   include_package_data=True,
> ```
>
> But I think there should be better ways to achieve these.
>

​Overriding only the `install` will make bdist_wheel​ produce the wrong
result. There's also the `develop` command. Some ideas about what commands
you might need to override:
https://github.com/pytest-dev/pytest-cov/blob/master/setup.py#L30-L63

An alternative approach would be to create a custom Extension class, check
this https://github.com/cython/cython/tree/master/Cython/Distutils for
ideas.

Unfortunately the internals of distutils/setuptools aren't really well
documented so you'll have to rely on examples, simply reading distutils
code, coffee or even painkillers :-)
​


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] matrix: python_versions x supported_plattforms, cross-compiling vs VM

[Ionel Cristian Mărieș via Distutils-SIG]

On Fri, May 27, 2016 at 2:25 PM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:

> I don't get what you want to say.
>
> If you are maintainer, then there is no "my platform". There is matrix:
>

​Missing the context, but didn't he write that from user perspective?

One could argue that​ getting old versions just because there's a wheel
ain't the best idea. Plus users can always pin the dependency to the
"right" version (the one that has wheel for their platform). Functionally
nothing is missing, it's an argument about default behavior.





Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] If you want wheel to be successful, provide a build server.

[Ionel Cristian Mărieș via Distutils-SIG]

On Wed, May 25, 2016 at 10:13 AM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:

> I do that for Windows because installing VS is an order of magnitude more
> difficult than installing gcc on Linux/UNIX but again: not willing to do
> extra work on that front (sorry).


He may accept a PR with Travis configuration to build the wheels though ...
Using that manylinux docker image should be easy enough on Travis.​

​On the other hand, there might be weird dependencies and the wheel don't
build well on the manylinux container - so there's still some extra effort​
for the maintainer.

A simpler package would probably make a better discussion.

PS. To  build all the manylinux wheels for a package you only need to run
something like:
docker run -itv $(pwd):/code quay.io/pypa/manylinux1_x86_64 bash -c 'set
-eux; cd code; rm -rf wheelhouse; for variant in /opt/python/*; do rm -rf
dist build *.egg-info && $variant/bin/python setup.py clean --all
bdist_wheel; auditwheel repair dist/*.whl; done; rm -rf dist build
*.egg-info'

​


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] comparison of configuration languages

[Ionel Cristian Mărieș]

On Fri, May 13, 2016 at 9:22 PM, Brett Cannon <br...@python.org> wrote:

> No need to think; the decision is made and it's TOML. I know Chris doesn't
> mean to stir up trouble, but at this point if someone wants to propose
> something other than TOML they are going to have to write their own PEP.


​Not asking for any change but has anyone looked at libconfig
<http://www.hyperrealm.com/libconfig/libconfig_manual.html>? ​It looks
quite interesting: simple grammar and nesting support. What do you think of
it?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] comparison of configuration languages

[Ionel Cristian Mărieș]

On Tue, May 10, 2016 at 10:38 AM, Alex Grönholm <alex.gronh...@nextday.fi>
wrote:

> So far the ONLY objective problems with YAML seems to be the problematic
> implementation named PyYAML. If this is really the case, I'd gladly help
> build a better one just to prevent TOML from being chosen for this task.
> That we're even *considering* building something as important as this on
> an unstable standard is pretty horrifying to me in itself.
>

​Just my two cents here: every time, but every every time,​ I have to
google around about how to create a multi-line string in YAML. There are
too many ways to write the same thing. And lets not forget those damn
sexagesimal literals. The complexity of that language is beyond repair,
it's not a *library* problem. Just look at insanities like this
<http://stackoverflow.com/questions/3790454/in-yaml-how-do-i-break-a-string-over-multiple-lines/21699210#21699210>
​or this <http://blog.teamlazerbeez.com/2009/04/15/yaml-gotchas/>​.

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] wheel including files it shouldn't

[Ionel Cristian Mărieș]

On Tue, Apr 26, 2016 at 5:11 PM, Paul Moore <p.f.mo...@gmail.com> wrote:

> > It looks like you have published a wheel built from a dirty checkout. The
> > 1.1.3 zip sdist produces a clean wheel, as expected. You should use
> > https://pypi.python.org/pypi/check-manifest in your release process.
>
> Ah, yes. enum/py35_test_enum.py is not part of the source tree or
> sdist, but is in the "enum" package directory, so will get picked up
> by packages=['enum']


​So yes, technically check-manifest don't have anything to do with
bdist_wheel (it does checks for sdist). But most probably it would had​
complained about unversioned file going into the sdist.

Maybe there should be a similar tool for bdist_wheel, "check-wheel" anyone?
What other checks could it have?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Current Warehouse Problems

[Ionel Cristian Mărieș]

On Mon, Apr 25, 2016 at 5:46 PM, Donald Stufft <don...@stufft.io> wrote:

>
> Primarily it did that so that it could dynamically reject file uploads
> without having to buffer them entirely in memory or on disk. Without
> something asynchronous to the Python process then we end up having a hard
> limit set in whatever the WSGI server is that buffers files to disk or
> rejects file uploads over a certain size.
>

​Sounds like a webserver feature (being able to stream the request​ body)
rather than a constraint that flows from the types of syscalls it use.
Doesn't gunicorn (prefork) allow streaming the request body?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Current Warehouse Problems

[Ionel Cristian Mărieș]

Probably none of my damn business but why does Warehouse use
gevent/eventlet? Does it really need them? Are there hosting constraints
that severely limit available RAM (so threads/processes aren't an option)?


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Sun, Apr 24, 2016 at 6:00 PM, Donald Stufft <don...@stufft.io> wrote:

>
> > On Apr 24, 2016, at 10:49 AM, Phil Thompson <p...@riverbankcomputing.com>
> wrote:
> >
> > I am currently unable to upload to warehouse and get...
> >
> > ConnectionError: ('Connection aborted.', BrokenPipeError(32, 'Broken
> pipe'))
> >
> > ...from twine.
> >
> > Is this a known problem?
> >
> > Thanks,
> > Phil
> > ___
> > Distutils-SIG maillist  -  Distutils-SIG@python.org
> > https://mail.python.org/mailman/listinfo/distutils-sig
>
>
> Yea I’m working on fixing it. We’ve had some problems with gevent/eventlet
> either taking progressively more time on every single request (gevent) or
> blocking forever on uploads to S3 (eventlet). This PR reverts an earlier
> change to attempt to work around it
> https://github.com/pypa/warehouse/pull/1110 and once that lands I’ll have
> another PR switching away from eventlet.
>
> -
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Parked Names in PyPI under user rodmena

[Ionel Cristian Mărieș]

On Fri, Apr 22, 2016 at 1:14 AM, Chris Barker <chris.bar...@noaa.gov> wrote:

> If that author were to suddenly decide to publish some malware under that
> name -- it would get a  lot of traffic!


​That's the problem with badly chosen names.​ I mean, what do you expect
when you give a name taken 3 years ago to your project?

Mypy is a poor name anyway, it's hard/ambiguous to spell and write [1], and
doesn't tell anything about functionality.

This is hard to understand, especially if you don't know any other language
than English, but for non-native English speakers these things really
matter.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Parked Names in PyPI under user rodmena

[Ionel Cristian Mărieș]

On Fri, Apr 22, 2016 at 1:14 AM, Chris Barker <chris.bar...@noaa.gov> wrote:

> it has published ONE version, in 2011.


Have you actually checked? There are 40 releases since 2009: ​
https://pypi.python.org/pypi/mypy/json​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

[Ionel Cristian Mărieș]

On Mon, Apr 18, 2016 at 11:47 PM, Chris Barker <chris.bar...@noaa.gov>
wrote:

>
> I'm suggesting that the "in perpetuity" bit is NOT a good way to go --
> packages are abandoned, and the longer this goes on, the more issues will
> arise.
>
>

​Problem is cat's out of the bag here. There are three issues:

   - Can't just change the rules underneath everyone. If we'd be making a
   package repository today, it would be fine - everything would know the
   rules. There's a huge surprise factor here and a recipe for drama if this
   is changed. If we'd change this perpetuity rule it wouldn't be possible to
   let everyone know about it - read receipts for email don't really exist.
   - Would taking mypy package from random Chinese dude no one seems to
   care about be fair? First release of mypy is in 2009
   <https://pypi.python.org/pypi/mypy/json> while mypy-lang's first commit
   is in​ 2012. Jukka would had done well if he'd used a different name for
   the project, or resolved the ownership issue back then.
   - Where do you draw the line for "abandoned"? Whom would you allow to
   confiscate ownership? It's impossible to come up with a non-arbitrary
   set of rules.

Plus I'm pretty sure the Chinese dude didn't even read or understood the
mail - we're talking about taking his package while he didn't even reply.
Seriously? Give it time it will sort itself out.
Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The mypy package

[Ionel Cristian Mărieș]

On Sat, Apr 16, 2016 at 2:29 AM, Guido van Rossum <gu...@python.org> wrote:

> Both Donald and myself have approached the owner (zsp...@gmail.com) but
> not received any response.
>

​Have you considered getting someone to write an email in Chinese?​ I
suspect he did not understand what was asked in Enligsh.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] pip install -e foo (without Repo URL)

[Ionel Cristian Mărieș]

On Fri, Apr 15, 2016 at 1:05 PM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:

> This:
>
>  pip install -e
> ​​
> third-party-foo-lib
>
> should be the same as:
>
>  pip install -e git+https:///@mydevbranch#egg=third-party-foo-lib
>

In the first form, how would you tell pip which branch you want?​ (assuming
you don't want whatever is default)

If you have a local directory `​third-party-foo-lib` would that take
precedence over a scm checkout?

​There would need to be a way to add this extra metadata (scm url and
default branch)​ in distributions ... uh, that means changing
setuptools/distutils? That means adoption issues, people won't always have
latest and greatest.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] For maximum performance, Python packages are best installed as zip files.

[Ionel Cristian Mărieș]

On Mon, Apr 11, 2016 at 4:00 PM, Paul Moore <p.f.mo...@gmail.com> wrote:

> you wouldn't typically install
> each application in its own directory and add that directory to
> $PATH.], so why do the equivalent with sys.path?
>

​Funny that Nixos and Redhat's SCLs​ do exactly that with $PATH other
vars:-)





Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] For maximum performance, Python packages are best installed as zip files.

[Ionel Cristian Mărieș]

On Mon, Apr 11, 2016 at 2:53 PM, Marius Gedminas  wrote:

> - multiple zipped eggs were slowest


​Afaik importing became slower and slower as you had more more eggs around.
Haven't investigated what actually was the cause as I don't use eggs
anymore but the idea that zips are good for performance is wrong - you need
to look at a lot of zips (and unpack) to see what's importable. The zip
importing caches worse than stating lots of directories, since it needs to
cache file content while unzipped only needs metadata - correct me if I'm
wrong.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to deprecate a python package

[Ionel Cristian Mărieș]

What's wrong with a new release that just depends on replacement (assuming
there's identical API)? This might be of help:
https://pypi.python.org/pypi/pypi-alias

If there are API changes or other breakages then maybe a release with a
wrapper that emits warnings would be better and generate less
surprise/anger.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Tue, Apr 5, 2016 at 9:46 PM, Thomas Güttler <guettl...@thomas-guettler.de
> wrote:

> I wasted some time because I used a deprecated python package.
>
> I asked the maintainer to remove it, and he looked at the usage
> statistics: I still gets
> downloaded.
>
> What is the official way to deprecate a python package?
>
> Related discussion:
>
>
> https://github.com/riklaunim/django-ckeditor/issues/60#issuecomment-205021579
>
> Regards,
>   Thomas Güttler
>
> --
> http://www.thomas-guettler.de/
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] question re: local development workflow / egg-info / synced directories

[Ionel Cristian Mărieș]

On Thu, Mar 31, 2016 at 1:20 PM, Chris Jerdonek <chris.jerdo...@gmail.com>
wrote:

> If this feature were working in setuptools, would pip need any changes
> to "install -e" to allow passing along this extra info to setuptools,
> or is there already a mechanism to allow pass-through of extra
> setuptools options?
>

Pip install has the --install-option and --global-option​ arguments, try
your luck with them - they are for fairly advanced usecases. Pip already
passes other options so there's risk of breakages or weird issues if you
pass conflicting options.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] question re: local development workflow / egg-info / synced directories

[Ionel Cristian Mărieș]

On Thu, Mar 31, 2016 at 9:22 AM, Chris Jerdonek <chris.jerdo...@gmail.com>
wrote:

> It would be nice if pip-installing a project directory in editable
> mode didn't require writing to the project directory. Is there a
> fundamental reason it needs to?
>

​I'd speculate that no one was annoyed enough to fix it.​

You could manually create the egg-info (setup.py egg_info
--egg-base=somewhere) and do the linking manually. I'm prty sure my
suggestion will raise some eyebrows here :)



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] question re: local development workflow / egg-info / synced directories

[Ionel Cristian Mărieș]

On Thu, Mar 31, 2016 at 3:03 AM, Chris Jerdonek <chris.jerdo...@gmail.com>
wrote:

> When developing locally, however, the sync process mounts the synced
> directory "over" the directory that was initialized at Docker-build
> time. Thus the egg-info directories are missing from the synced
> version of the directory.
>

​Are you mounting the site-packages or something else?​


> 2. install the projects in editable mode locally on my Mac so the
> egg-info directories will also sync over (but I'm not sure if egg-info
> directories are sufficiently cross-platform), or
>

​Assuming you mount the site-packages this should be fine as long as the
paths are the same, this is because easy-install.pth will contain absolute
paths​. When you do `setup.py develop` an entry is added in
easy-install.pth and that egg-info dir is created.

Note that the egg-info metadata is mostly used for entrypoint discovery
(eg: you use console_scripts
<https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation>
or plugin system
<https://pytest.org/latest/writing_plugins.html#making-your-plugin-installable-by-others>
based on entrypoints).

Also, develop installs allow overriding the develop command, so they might
do something extra (like pytest-cov "installs" a pth file for the
subprocess support).

That means you can just symlink or use a pth
<https://docs.python.org/2/library/site.html?highlight=pth> file if you
don't care about any of those features.




Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] python_version>="2.7" environment marker difficulties

[Ionel Cristian Mărieș]

I think most users will understand
<https://github.com/ionelmc/pytest-benchmark/issues/42> that they need to
upgrade their pip/setuptools. If they complain about Ubuntu not shipping
recent tooling or whatever then just send them to the Ubuntu bug tracker
:-)

Regarding your issue, since you don't depend on minor python version you
could easily publish one wheel for py2 and one for py3. This won't need env
markers and will avoid wheel poisoning issues, in most cases at least. But
this complicates the release process - is it worth it?


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Mon, Mar 21, 2016 at 1:40 PM, Michael R. Crusoe <cru...@ucdavis.edu>
wrote:

> Hello,
>
> To support a dependency[0] which has a different name for its Py2 & Py3
> versions, our program schema_salad uses the "python_version" environment
> marker.
>
> This seems to not be supported when users have older setuptools
> installed[1]
>
> With setuptools before version 17.1 one gets
>
> error in schema-salad setup command: Invalid environment marker:
> python_version>="2.7"
>
> I tried to bundle a newer version with ez_setup.py but that isn't working
> either:
> https://github.com/common-workflow-language/schema_salad/commit/04a956dbef40b32ef9c486ddab4dcff544dc2c65#commitcomment-16745845
>
> "ez_setup() bootstraps transparently if you're using python setup.py
> install but not for pip install of the same package (where it complains
> that you need to upgrade setuptools first)"
>
> Code is at
> https://github.com/common-workflow-language/schema_salad/blob/envmarker-test/setup.py#L45
>
> Is there a better way to deal with the divergent names for our dependency?
>
> Thanks in advance,
>
> [0] https://pypi.python.org/pypi/avro vs
> https://pypi.python.org/pypi/avro-python3
> [1]
> https://github.com/common-workflow-language/schema_salad/issues/17#issue-141147041
>
> --
> Michael R. Crusoe CWL Community Engineer cru...@ucdavis.edu
> Common Workflow Language projectUniversity of California, Davis
> https://impactstory.org/MichaelRCrusoe http://twitter.com/biocrusoe
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Source code for wrapper EXEs

[Ionel Cristian Mărieș]

These are the sources:
https://bitbucket.org/pypa/setuptools/src/tip/launcher.c


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Sat, Jan 23, 2016 at 11:21 PM, Ivan Pozdeev via Distutils-SIG <
distutils-sig@python.org> wrote:

> Where can I find sibj for cli*.exe/gui*.exe? In the published source code (
> https://pypi.python.org/packages/source/s/setuptools/setuptools-19.4.tar.gz#md5=c5a7d90c1e0acf8c4ec5c2bf31bc25b5)
> and even the BitBucket repo, they are already in compiled form.
>
> --
> Regards,
> Ivan
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Release/file cannot add file

[Ionel Cristian Mărieș]

On Mon, Dec 14, 2015 at 11:00 PM, Kevin Glisson <kevgl...@gmail.com> wrote:

> I believe this might have something to do with the fact that I took over
> the namespace from a different package. My package has never successfully
> been publish to pypi so I am not working about breaking anyone's builds.
>
> Package in question:
> https://pypi.python.org/pypi/lemur
>

​Did you have previous releases that were removed?

https://pypi.python.org/pypi/lemur/json indicates you had a 0.2.1 release
at least ...​

PyPI don't allow re-uploading the same release. Use different version
number instead.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Installing packages using pip

[Ionel Cristian Mărieș]

On Wed, Dec 9, 2015 at 12:51 AM, Greg Ewing <greg.ew...@canterbury.ac.nz>
wrote:

> Are you sure you were actually unlinking the old file
> and creating a new one, rather than overwriting the
> existing file? The latter would certainly cause trouble
> if you were able to do it.
>

​I had two instances of this ​problem:

   - pip upgrading (pip removes old version first) some package with C
   extensions while processes using that still runs
   - removing (yes, rm -rf, not inplace) and recreating a virtualenv while
   processes using that still runs

It's wrong to think "should be safe on linux". Linux lets you do very
stupid things. But that don't make them right or feasible to do in the
general case.

You can do it, sure, but the utility and safety are limited and very
specific in scope. You gotta applaud Windows for getting this right.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Installing packages using pip

[Ionel Cristian Mărieș]

On Wed, Dec 9, 2015 at 2:18 AM, Nathaniel Smith <n...@pobox.com> wrote:

> Just want to make sure that the actual semantics here are clear -- there's
> nothing mysterious about the Unix semantics, and it's pretty easy to
> predict what will work and what won't once you understand what's going on.


​You don't have any guarantees that running process won't try to use stuff
from disk later on do you?  If it segfaults (and it does in my "general
usecases") it's hard to debug - you got nothing conveniently on disk​. And
no, "upgrading libc" is not a general usecase, it's just one of those few
things that work because they were written in a very specific way, and you
should not apply that technique in the general usecase.

If you want, I can provide you some reproducers but lets not continue this
"but, seriously, it works fine for me" kind of discussion.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Installing packages using pip

[Ionel Cristian Mărieș]

On Mon, Nov 16, 2015 at 6:25 PM, Marius Gedminas <mar...@gedmin.as> wrote:

> What you can do Linux that you cannot do on Windows is delete a shared
> library file while it's mapped into a process's address space.  Then
> Linux lets you create a new file with the same name, while the old file
> stays around, nameless, until it's no longer used, at which point the
> disk space gets garbage-collected.  (If we can call reference counting
> "garbage collection".)
>
> The result is as you said: existing processes keep running the old code
> until you restart them.  There are tools (based on lsof, AFAIU) that
> check for this situation and remind you to restart daemons.
>

​Not sure what exactly was going on but whenever I did that on linux I got
the most peculiar segfaults and failures. It is certainly not a safe thing
to do, even if linux lets you do it.​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] How to exclude a directory from a module that has tests?

[Ionel Cristian Mărieș]

On Fri, Nov 13, 2015 at 1:50 PM, Nagy László Zsolt <gand...@shopzeus.com>
wrote:

> The problem is that there is a "test" directory and it is added to the
> source distribution. I want to exclude that. I know that there is an
> "exclude" parameter for find_packages(). But this is not a package. This is
> a single module. How do I exclude a directory then?


​People usually include the tests in their sdist - you might want to do
that too. If you still don't then you can control the contents of sdist via
MANIFEST.in - "test"​ is inlcuded by default afaik so just add a "prune
test" in MANIFEST.in. Still, take note that sdist is not what gets
installed in site-packages, so you should have all your source files in it.
IOW: don't do prune test.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Ionel Cristian Mărieș]

On Tue, Nov 10, 2015 at 3:05 AM, Nathaniel Smith <n...@pobox.com> wrote:

> So apparently if you use 'python -m venv' to create a new *venv* while
> inside a *virtualenv*, then it seems to complete successfully but
> leaves you with a venv that doesn't contain pip. At least on my
> machine (up-to-date Debian testing).
>

​How is this relevant? Are you trying to suggest that `pip -p
path/to/python` would​ exhibit the same class of bugs and failures
`virtualenv -p path/to/python` has?

​I'm not saying it wouldn't but​ ​how much of that `no pip in venv`​ bug is
a virtualenv issue or a problem with the design of a pip launcher or
standalone pip? It seems to me that it's a bit irrelevant, but correct me
if you're not using Ubuntu (were venv is broken in ludicrous ways). Plus
virtualenv is broken in it's own way (bootstrapping, see this
<https://github.com/pypa/virtualenv/pull/697> and this
<https://github.com/ionelmc/virtualenv/>) ...



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Ionel Cristian Mărieș]

On Sat, Nov 7, 2015 at 12:24 AM, Donald Stufft <don...@stufft.io> wrote:

> Well, it’s not really a launcher no, but you’d do ``pip -p python2 install
> foo`` or something like that. It’s the same UI. Having just a “launcher” I
> think is actually more confusing (and we already had that in the past with
> -E and removed it because it was confusing). Since you’ll have different
> versions of pip in different environments (Python or virtual) things break
> or act confusingly.
>

​That can't be worse than the current situation. And I'm not asking to
bring `-E` back.

The idea is that the pip bin becomes a launcher file, just like py.exe - it
would just try to discover an appropiate python and run `-mpip` with it.
This doesn't even need​

​to be implemented in pip - linux distributions can do this.

For windows it's more tricky - but if Python on windows has getpip ​why
can't it bundle a pip.exe, just like py.exe?

Another issue that is being conflated here is the most frequent scenario:
using virtualenv activation. We should should be really be talking about
deprecating the activation shell scripts - messing with $PATH is what we
should really look at - not deprecating `pip` bin over to the overly
tedious `python -mpip`.




Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Ionel Cristian Mărieș]

On Thu, Nov 5, 2015 at 11:08 PM, Donald Stufft <don...@stufft.io> wrote:

> Currently pip installs a number of commands like ``pip``, ``pipX`` and
> ``pipX.Y`` where the X and X.Y corresponds to the version of Python that
> pip
> is installed into. Pip installs into whatever Python is currently
> executing it
> so this gives some ability to control which version of Python you're
> installing
> into (``pip2.7`` for Python 2.7 etc).
>

​Why not consider having a "pip" launcher?​ Seems the obvious thing to me -
python has the "py" launcher on windows and it works great!

Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using
python3.5 - just like the "py" launcher.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] The future of invoking pip

[Ionel Cristian Mărieș]

On Fri, Nov 6, 2015 at 11:13 PM, Donald Stufft <don...@stufft.io> wrote:

> Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using
> python3.5 - just like the "py"
>
>
> Isn't this basically what the third option is?  Just the launcher is also
> the entire program.
>

​If you mean the initial mail you have send, I only saw two proposals:
`python -mpip` and something with zipfiles. Not sure if having a zipfile
around counts as a launcher, you wouldn't call something a launcher if it
contains the target completely no?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Environment markers: ready for prime time?

[Ionel Cristian Mărieș]

On Wed, Oct 28, 2015 at 7:08 PM, Marius Gedminas <mar...@gedmin.as> wrote:

> - does the pip version matter at all?  I think not; please correct me if
>   I'm wrong.
>

​From what I see, pip only supports env markers in sdists since 6.0 (
https://github.com/pypa/pip/pull/2153) so I guess one can only count on env
marker suport since 6.0, right?​

How much usage do the pre-6.0 pip versions get?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Please don't impose additional barriers to participation

[Ionel Cristian Mărieș]

On Wed, Oct 28, 2015 at 10:31 AM, M.-A. Lemburg <m...@egenix.com> wrote:

> I agree with Ben. Discussions on PEPs need to happen on mailing lists,
> not hidden away on some issue tracker or PR ticket.
>

​I think some balance is needed here. Every so often discussions on the
mailing list get so disorganized and slide into so many irrelevant things I
can't afford to participate​. I think the PR thing should at least be tried
and MAL/Ben haven't provided any pertinent arguments against making a
github account anyway.

​Plus the PyPA shown willingness to accommodate feedback from the
mailinglist​. I'd expect draft updates will be posted once in a while on
distutils-sig for people who don't have a web browser or github account.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Ionel Cristian Mărieș]

On Mon, Oct 26, 2015 at 8:04 AM, Nathaniel Smith <n...@pobox.com> wrote:

> [TBD: should builds be performed in a fully isolated environment, or
> should they get access to packages that are already installed in the
> target install environment? The former simplifies a number of things,
> but Robert was skeptical it would be possible.]
>

​Would be wasteful not to allow it. But then, some people might want
isolation. Whom should be able to switch isolation on? Users? Publishers?​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Second draft of a plan for a new source tree / sdist format

[Ionel Cristian Mărieș]

On Mon, Oct 26, 2015 at 8:04 AM, Nathaniel Smith <n...@pobox.com> wrote:

> When this sdist is built, the resulting wheel MUST have metadata
> which is identical to the metadata present in this file, except that
> any fields with value ``__SDIST_DYNAMIC__`` in the sdist may have
> arbitrary values in the wheel.
>
> A valid sdist MUST NOT use the ``__SDIST_DYNAMIC__`` mechanism for
> the package name or version (i.e., these must be given statically),
> and these MUST match the {PACKAGE} and {VERSION} of the sdist as
> described above.
>
> [TBD: do we want to forbid the use of dynamic metadata for any
> other fields? I assume PyPI will enforce some stricter rules at least,
> but I don't know if we want to make that part of the spec, or just
> part of PyPI's administrative rules.]
>

​Unless I misunderstood the core goal of this new sdist (to be able to know
the dependencies statically), it doesn't make sense to allow mixing things.
Is there an usecase for dynamic requirements​? In that situation users can
just as well use the current sdist format. There are no advantages to using
the new sdist format if your requirements are dynamic right?

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] build system abstraction PEP

[Ionel Cristian Mărieș]

On Tue, Oct 27, 2015 at 1:23 AM, Robert Collins <robe...@robertcollins.net>
wrote:

> wheel: flit wheel -d $
> ​​
> OUTPUT_DIR


What's expected to happen if there are multiple files produced in
$​OUTPUT_DIR? Is it an error?

Also, doesn't this pep overlap with PEP 426? Shouldn't these ideas be
incorporated there? It seems that only the command metadata is missing from
PEP 426.

Another thing, I've noticed there's a "develop" command in this draft. I
think this is confusing, I'd expect it to be a "install" command (and
that's what it is now in setuptools). It should be renamed to something
more clear, like "inplace-build" and leave the installing to pip.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Remove distutils, was: red, green, refactor ...

[Ionel Cristian Mărieș]

On Thu, Oct 22, 2015 at 1:50 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk>
wrote:

>
> I've thought about the migration path with distil, which uses a
> declarative metadata format (superset of PEP-426 as it was a while ago)
> where the actual metadata is extracted from setup.py files in releases
> already on PyPI. This works well for simple distributions which don't do
> anything fancy in setup.py, such as extending build commands to create
> files on the fly which are then installed etc. In my early testing, distil
> (which uses no distutils or setuptools code) could install and package
> distributions which were pure-Python as well as package, build and install
> ones with C extensions and even Fortran extensions. I haven't done much
> work on it for a while due to other commitments, but when I had the time to
> work on it, I noted precious little interest from distutils-sig (yes, I
> know we're all volunteers, but one person can only do so much).


​What does distil do to achieve this? A setuptools polyfill? Just parsing
​setup.py and inspecting file layout?

Is there any code for this or you're just talking about an idea? I couldn't
find any distil project in https://bitbucket.org/vinay.sajip/ ...



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Remove distutils, was: red, green, refactor ...

[Ionel Cristian Mărieș]

On Wed, Oct 21, 2015 at 3:10 PM, Antoine Pitrou <solip...@pitrou.net> wrote:

> (3) because distutils is part of the standard library and setuptools is
> most likely unwelcome there :-)
>

​Well, it's not dead yet. Sorry, I mean,​ good enough to be included in the
stdlib :-)

But seriously, is it correct to assume that it's not there for largely the
same reasons pip ain't in stdlib? (and yes, getpip is in stdlib)

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] red, green, refactor OR red, green, new feature?

[Ionel Cristian Mărieș]

On Wed, Oct 21, 2015 at 11:00 AM, Ben Finney <ben+pyt...@benfinney.id.au>
wrote:

> >  1. red
> >  2. green
> >  3. new feature.
>
> The latter isn't a workflow I recognise. It appears to confuse the
> levels of working.
>

​I think Thomas is making a subtle joke on the state some of the packaging
tools​ are in. Especially the older ones.

Then again, sometimes refactoring is very hard. Is rewriting from scratch
better?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PyPi not allowing duplicate filenames

[Ionel Cristian Mărieș]

On Wed, Oct 14, 2015 at 7:43 PM, Chris Barker <chris.bar...@noaa.gov> wrote:

> some packages were unable to work with the postN suffix.


​Can you elaborate a bit more here?​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PyPi not allowing duplicate filenames

[Ionel Cristian Mărieș]

On Wed, Oct 14, 2015 at 11:04 PM, Donald Stufft <don...@stufft.io> wrote:

> Generally within 60-120 seconds it’s available in mirrors (most of them
> resync once a minute). If anyone has downloaded it then they will have
> pretty much permanently cached the package, first in the download cache and
> then again in the wheel cache (assuming it wasn’t a wheel already, and they
> had that enabled). The original package was NumPy. It had 30,982 downloads
> in the last day, so we can average that out to 1290 downloads an hour or 21
> downloads a minute. If it takes you two minutes to notice it and delete it,
> then there are ~40 people who already have the original version cached and
> who will not notice the updated version.
>

​This reminds me of Gmail's "unsend" feature where email would be delayed
10 seconds or something, giving a window to press the unsend button. Maybe
something like that could be implemented? Like a minute or two in which you
could unpublish? And a --no-regrets mode of course​, for people that want
to live the moment :-)



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] rst not rendered on pypi

[Ionel Cristian Mărieș]

This looks suspicious:

*A twice-folded Möbius strip, created with VoroPy's
``moebius_tri -i 2 out.e``. Visualization with
`ParaView <http://www.paraview.org/>`__.*

Regardless, you should use https://pypi.python.org/pypi/readme to check it
(that's what PyPI uses for rendering).


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Tue, Oct 13, 2015 at 8:03 PM, Nico Schlömer <nico.schloe...@gmail.com>
wrote:

> Hi everyone,
>
> I'm trying to get my README.rst [1] display properly on my PyPy project
> [2], but for some reason it's displayed as raw text. The file was created
> from a README.md [3] via
> ```
> pandoc README.md -o README.rst
> ```
> Any hints on what may have been going wrong?
>
> Cheers,
> Nico
>
>
> [1] http://chunk.io/f/f4385eda77de4ed78f8eba8cc8d8c8b6
> [2] https://pypi.python.org/pypi/voropy
> [3] https://github.com/nschloe/voropy/blob/master/README.md
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] sampleproject: use tox?

[Ionel Cristian Mărieș]

On Sat, Oct 10, 2015 at 5:11 PM, Nick Coghlan <ncogh...@gmail.com> wrote:

> This unfortunately isn't a good idea, at least for folks aiming to
> publish their first project. While it's well-intentioned, the problem
> with it is that it can be *tremendously* demotivating for folks that
> aren't already familiar with all those additional niceties, as it hits
> newcomers over the head with how much they still have to learn.
> Testing in particular is problematic, as writing tests involves
> writing programs about programs. That means you need to already
> understand a fair bit about programs *and* about how programs fail, to
> appreciate why it may make sense to write a second program to make
> sure the first program is behaving as you expect. Folks that already
> have that knowledge aren't going to need the packaging guide to tell
> them how to do it, while folks that don't have that knowledge are
> going to be confused by a digression on testing and documentation when
> they're wanting to learn about packaging and distribution.
>

​This begs the conception of yet another opinionated guide for X, Y and Z
in Python. I believe we got plenty of those, and what encouraged their
creation is exactly this sort of thinking.

The problem is that none of them are really comprehensive, well maintained
or authoritative enough (we wouldn't have this discussion if there was).
They may have been "well-intentioned" but they only create confusion now ...

What if there was something official-ish that takes the packaging guide
further, for people that want more than just packaging? It seems that there
is some demand.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] sampleproject: use tox?

[Ionel Cristian Mărieș]

On Fri, Oct 9, 2015 at 12:43 PM, Paul Moore <p.f.mo...@gmail.com> wrote:

>
> The sample project is not intended for that purpose. It's a good
> starting point for something like that, but that's not its purpose.
>
> Paul
>
> PS I sympathise with your wish for a "do this to set up your first
> project" beginner's guide. I've wanted one of those myself for a long
> time now. But I don't believe such a thing exists, unfortunately.


​Should we at least give some pointers as to what people should look at for
a fully fledged project? Like a lists with examples/templates covering all
the variants. Eg:

"PyPA's sample projects only covers the packaging aspect of a project. For
more exhaustive examples take a look at cookiecutter templates, barry's
sample, ogrisel's appveyor demo, this and that etc etc"

How about something like that?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Ionel Cristian Mărieș]

On Fri, Oct 9, 2015 at 7:05 PM, Chris Barker <chris.bar...@noaa.gov> wrote:

> How many people can join a hangout? we may be bumping up against that
> limit :-)


​AFAIK there's no limit on the number of people that can listen in. Also,
Hangouts can record video (the "On Air" thing).​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Ionel Cristian Mărieș]

On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin <oscar.j.benja...@gmail.com>
wrote:

> I think this satisfies all of the requirements for static metadata and
> one-to-one correspondence of source wheels and binary wheels. If numpy
> followed this then I imagine that there would be a single source wheel
> on PyPI corresponding to the one configuration that would be used
> consistently there. However numpy still needs to separately release
> the code in a form that is also usable in all of the many other
> contexts that it is already used.
>

​Can't that configuration just be the build defaults​? There would be a
single source but with some preset build configuration. People with
different needs can just override those.

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Ionel Cristian Mărieș]

On Thu, Oct 8, 2015 at 4:51 PM, Oscar Benjamin <oscar.j.benja...@gmail.com>
wrote:

> It depends. If you're using numpy from pure Python code the difference
> between mkl and otherblas is probably irrelevant. So in most cases
> you'd want to be able to depend just on "numpy" but in some cases
> you'd need to be more specific. Perhaps you could solve that with
> "provides"...
>
> Really though it's probably best to keep the set of binaries on PyPI
> internally consistent and not try to represent everything. My point
> earlier was that regardless of what goes on PyPI as the official numpy
> wheel there will be many people using the numpy code in other ways. If
> pip is not the only consumer of a source release then it's not really
> reasonable to dictate (and redesign in a less human-friendly way) its
> layout purely for pip's benefit.
>

​Yes indeed. But then shouldn't we talk about proper dependency resolution,
compatible releases, meta packages and stuff like that? Unless I completely
misunderstood the discussion here (quite probable :-) then this whole
multiple source distributions idea is more like a workaround.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

[Ionel Cristian Mărieș]

On Thu, Oct 8, 2015 at 4:01 PM, Donald Stufft <don...@stufft.io> wrote:

> One of the features in the original PEP was the ability to produce multiple
> different Wheels from the same source release much like how Debian does.
> e.g.
> numpy-1.0.newsdistthing could produce numpy-pyopenblas-12.6.whl and
> numpy-mkl-7.8.whl, etc etc where there would be a bunch of names/versions
> that
> would differ from the name/version of the original sdist thing that was
> being
> proposed.
>

​Sorry if this sounds obtuse but isn't that useless overspecialization?
They can just publish `numpy-mlk` and `numpy-​thatblas` or whatever on
PyPI, and that will even work better when it comes to dependencies. I mean,
if you build something for `numpy-mkl` then it wouldn't work on a
`numpy-otherblas` anyway right?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Wed, Oct 7, 2015 at 4:42 PM, Ionel Cristian Mărieș <cont...@ionelmc.ro>
wrote:

> On Wed, Oct 7, 2015 at 3:18 PM, Donald Stufft <don...@stufft.io> wrote:
>
>> tox and setup.py test are not really equivalent. There’s no way (to my
>> knowledge) to test the item outside of a virtual environment. This is
>> important for downstreams who want to test that the package build and the
>> tests successfully are executed in their environment, not within some
>> virtual environment.
>
>
> ​H ... you're right. But making Tox not use virtualenvs is not
> impossible - much alike​ to how Detox is working, we could have a "Tax"
> (just made that up) that just skips making any virtualenv. It's a matter of
> making two subclasses and a console_scripts entrypoint (I think). I think
> it's a good name: ``use Tax instead of Tox if you wanna "tax" your global
> site-packages`` :-)
>

​Just for kicks, I verified this, it's not hard at all:
https://pypi.python.org/pypi/tax

Barry may want to look at it, in case he has too many tox.ini files to
copy-paste from :-)


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Wed, Oct 7, 2015 at 3:20 PM, Wes Turner <wes.tur...@gmail.com> wrote:

> > 2. The "test" command will install the "test_requires" dependencies as
> eggs. You will end up with multiple versions of the same eggs right in your
> source checkout.
>
> * is there no way around this?
> * is this required / spec'd / fixable?
>
​It's not that bad now, recent setuptools put the eggs in a ".eggs" dir -
so it's not as messy as before. ​


> > 3. The "test" command will install the "test_requires" dependencies with
> easy_install. That means wheels cannot be used.
>
> would it be possible to add this to wheel?
>
It's up to the maintainers of wheel/setuptools to figure this one out (or
not) I think. Either way, you should search through the distutils-sig
archives for clues/intentions, eg:
https://mail.python.org/pipermail/distutils-sig/2014-December/thread.html#25482

​




Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Wed, Oct 7, 2015 at 3:18 PM, Donald Stufft <don...@stufft.io> wrote:

> tox and setup.py test are not really equivalent. There’s no way (to my
> knowledge) to test the item outside of a virtual environment. This is
> important for downstreams who want to test that the package build and the
> tests successfully are executed in their environment, not within some
> virtual environment.


​H ... you're right. But making Tox not use virtualenvs is not
impossible - much alike​ to how Detox is working, we could have a "Tax"
(just made that up) that just skips making any virtualenv. It's a matter of
making two subclasses and a console_scripts entrypoint (I think). I think
it's a good name: ``use Tax instead of Tox if you wanna "tax" your global
site-packages`` :-)

We only need someone to do it.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Wed, Oct 7, 2015 at 6:13 PM, Erik Bray <erik.m.b...@gmail.com> wrote:

> > Lets not use `setup.py test`. It's either bad or useless.
>
> Says who?  Many of the projects I'm involved in use `setup.py test`
> exclusively and for good reason--they all have C and/or Cython
> extension modules that need to be built for the tests to even run.
> Only setup.py knows about those extension modules and how to find and
> build them.  Using `setup.py test` ensures that everything required to
> run the package (including runtime dependencies) is built and ready,


​Well ok, then it's not useless. :-)

For pure Python packages I think it's less important and can usually
> rely on "just run 'nose', or 'py.test'"  (or "tox" but that's true
> regardless of how the tests are invoked outside of tox).
>

That implies you would be testing code that you didn't install. That allows
preventable mistakes, like publishing releases on PyPI that don't actually
work, or do not even install at all (because you didn't test that).
`setup.py test` doesn't really allow you to fully test that part, but Tox
does.

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Wed, Oct 7, 2015 at 6:37 PM, Erik Bray <erik.m.b...@gmail.com> wrote:

> Which, incidentally, is a great reason for installable tests :)
>

Not really. Doesn't matter where you have the tests. It matters where you
have the code being tested.

Tests being installed is a mere consequence of the location of tests.
​


> Running in the source tree is great for development.  But when
> preparing a release it's great to be able to create an sdist, install
> that into a virtualenv, and run `package.test()` or `python -m
> package.tests` or whatever.  Occasionally catches problems with the
> source dist if nothing else.
>
​​
​As I said, I like the idea. It's just that it's not feasible right now.
Lets go over the issues again:

* Tests too bulky (pyca/cryptography)
* Tests can't be installed at all: ​
https://github.com/getpelican/pelican/issues/1409​
* Not clear how to install test dependencies. tests_require? extras? no
deps? What about version conflicts and way too many deps being installed.
Dependencies are like cars, they are very useful but too many of them
create problems.
* Real problems like standardized test output or run protocol are not
solved at all. Little benefit of doing it like this if you can't build good
CI tools around this.
* Workflows are under-specified. User are not guided to make quality
releases on PyPI.

​Maybe we should have a PEP that would specify/propose some concrete
solutions to all those?

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Tue, Oct 6, 2015 at 11:54 PM, Erik Bray <erik.m.b...@gmail.com> wrote:

> Skimming back through the rest of the thread I don't see too much
> support for 1).  The only argument against it is the need for
> specifying dependencies, etc., which really only impacts developers so
> long as the tests aren't *installed*, I think.  But there's also the
> question of what kinds of tests we're talking about.  I think unit
> tests should live in the .tests for a library.  Other
> kinds of tests I don't have a strong opinion about.
>

​I think there's some confusion here. The pain point with "inside" tests is
exactly the dependencies. And by dependencies I mean test dependencies,
we're talking about tests here :-)​

If you install two packages with "inside" tests, then how do you deal with
the version conflict of test dependencies? That's the big elephant in the
room everyone is ignoring :)

If you have to bend over backwards (to install the test dependencies) in
order to run the installed tests then what's the point of installing them
at all? It's far more safer to ask the user to just checkout the sources
and run the tests from there. Why completely mess up user's site-packages
just because you want to have this weird `python -mfoobar.tests` workflow?

I like the idea, I really do. But it's not for everyone. I strongly feel
that only projects that don't have any test dependencies should install the
tests, or provide the tests inside the package.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Wed, Oct 7, 2015 at 12:51 AM, Ben Finney <ben+pyt...@benfinney.id.au>
wrote:

> I think the above describes the standard way of declaring the test
> runner: The ‘setup.py test’ command.
>
> Now, I lament that more Python projects don't *conform to* that
> standard, but at least it exists.
>

​There's a very simple answer to that: easy_install (that's what `setup.py
test` will use to install deps). It has several design issue wrt how
packages are installed and how dependencies are managed.

Lets not use `setup.py test`. It's either bad or useless.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Tue, Oct 6, 2015 at 10:20 AM, Glyph Lefkowitz <gl...@twistedmatrix.com>
wrote:

> If you put your tests outside your package, then you can't install the
> tests for two packages simultaneously, because everyone's tests are just in
> the top-level package "tests".  This tends to infest the whole package,
> since then tests import things from each other using 'from tests import
> ...'.  This is recommended by the hitchhiker's guide, and seconded by <
> http://as.ynchrono.us/2007/12/filesystem-structure-of-python-project_21.html
> >.
>

​I don't want to be harsh here but arguments would be way more interesting
to discuss, as opposed to giving links to JPC's outdated packaging guide.
He's an exceptional developer but many of the things inside that article
are out of fashion (he disagrees about using console_scripts entrypoints​,
doesn't understand what src is for and so on).

I don't think anyone would ever intentionally put a "tests" package in
site-packages, why would you mention that?



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Tue, Oct 6, 2015 at 10:51 AM, Antoine Pitrou <solip...@pitrou.net> wrote:

> They should be inside the module. That way, you can check an installed
> module is ok by running e.g. "python -m mypackage.tests". Any other
> choice makes testing installed modules more cumbersome.
>

​Does that really make sense? I haven't heard of any user actually running
tests​
that way. To be honest I haven't ever ran Python's own tests suite as part
of a user installation.

​I've seen some projects that lump up lots of test data and crazy files in
their
packages tests and that created install issues​ (Pelican is one example,
pretty sure
there are others).

On the other hand, if the user really wants to run the tests he can just
get
the sources (that would naturally include everything)?

Seems odd to suggest something is a best practice without giving any clue
of how
test dependencies would be managed. Just because CPython does it doesn't
mean
libraries should.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Wed, Oct 7, 2015 at 2:23 AM, Robert Collins <robe...@robertcollins.net>
wrote:

>
> Hangon, there's clearly a *huge* gap in understanding here.
>
> pbr does *not* modify *anyones* setup.py output unless its enabled.


​Unless it's >=1.7.0. You can't blame setuptools having entrypoints for pbr
doing weird stuff to distributions by abusing said entrypoints.

For reference: https://bugs.launchpad.net/pbr/+bug/1483067 ​

There's nothing special about pbr here. It's not like it's the first
package doing dangerous stuff (distribute, suprocess.run, pdbpp). I really
like pdbpp, but you don't put that in production.

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Wed, Oct 7, 2015 at 1:04 AM, Antoine Pitrou <solip...@pitrou.net> wrote:

> > ​I think there's some confusion here. The pain point with "inside" tests
> is
> > exactly the dependencies.
>
> Is it your personal experience or some theoretical argument you're
> making?
>

I've published about 27 packages that have tests on PyPI. Out of those only
5 could run purely on stdlib unittest.​

That leaves me with 22 packages that need test tools like pytest/nose and
assorted plugins.


> > If you install two packages with "inside" tests, then how do you deal
> with
> > the version conflict of test dependencies?
>
> Well, how do you deal with the version conflict of non-test
> dependencies? How are tests supposed to be a problem here, while they
> usually have so few dependencies of their own?
>

​It's double the trouble to find compatible releases. Current tooling don't
resolve conflicts automatically.​ Maybe it's something handled better in
Conda for all I know but I don't use that.


> > If you have to bend over backwards (to install the test dependencies)
>
> While some packages may have non-trivial test dependencies, usual
> practice is for test suites to require the exact same dependencies as
> the rest of the package, + perhaps a test runner.
>

Can't relate to that - definitely not `usual practice` from my perspective.​


Since we're talking about good practice for the average package, it's
> not very useful to point out that 0.1% of PyPI packages may have
> excruciatingly annoying test dependencies.
>

​Already feeling guilty ... I hope you're finally happy now :-)
​


> > Why completely mess up user's site-packages
> > just because you want to have this weird `python -mfoobar.tests`
> workflow?
>
> Did you have such an experience or are you making this up for the sake
> of the argument?
>

​I got burnt by the pbr issue [1] once (cause mock has it as a run-time
dependency). I don't normally use `mock` but in the circle of hell I live
in someone else depended on it.​


​I don't look forward to that happening again, and I don't want to litter
my site-packages with useless test stuff. I already have too much stuff in
there.



> And just because you are not used to a "workflow" doesn't make it
> "weird" in any case.  Python itself uses such a workflow ("python -m
> test").


​It's weird in the sense that you have to do all these gymnastics to get
the test dependencies right​

​before running that. As I previously stated, I like the idea of `python
-mfoobar.test` - just that dependencies and scope make it weird and
impractival for *general* use.

​[1] https://bugs.launchpad.net/pbr/+bug/1483067​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Tue, Oct 6, 2015 at 12:51 PM, Wes Turner <wes.tur...@gmail.com> wrote:

> self-testable programs are really ideal (e.g POST power-on self test)
> relevant recent topical discussion of e.g
> CRC and an optional '-t' preemptive CLI parameter:
> https://github.com/audreyr/cookiecutter-pypackage/pull/52
>

​I would be interesting ​to talk about what's worth including in a
"self-test" feature.

Most suites aren't suitable for including as whole. You don't want to
include integration (functional) tests for sure :-)

There's also the ever-unanswered question of how to deal with test
dependencies. Some will think that it's ok to always install them, but then
again, after seeing how `mock` depends on `pbr` - and how `pbr` just
decides to alter your `setup.py sdist/bdist_*` output without being asked
or invoked has made me very wary of this practice. How I have to make sure
my python installs have certain versions of `pbr` or no `pbr` at all, every
time I want to build a package :-(



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Tue, Oct 6, 2015 at 3:51 PM, Antoine Pitrou <solip...@pitrou.net> wrote:

> The "src" convention is actually terrible when working with Python
> code, since suddenly you can't experiment easily on a VCS checkout, you
> have to do extra steps and/or write helper scripts for it.
>
> The fact that few Python projects, including amongst the most popular
> projects, use that convention mean it's really not considered a good
> practice, nor convenient.
>

​Convenience over correctness - I can understand that. Using virtualenvs
(or tox) is not always something people want. People get attached to
certain workflows, that's fine with me.​ But lets not confuse that with
what's right. Just because it's popular doesn't mean it anywhere close to
correct. It means it works, once in a while people hit some pitfalls,
suffer for it but continue the same way. The same people then complain
about "terrible" packaging experience in Python.

I think we should look at this more meticulously, not solely through the
perspective of what's popular.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Tue, Oct 6, 2015 at 3:13 PM, Antoine Pitrou  wrote:

> On Tue, 6 Oct 2015 07:07:31 -0400
> Donald Stufft  wrote:
> >
> > I've never, in my entire life [...]
>
> Can I suggest your entire life is an anecdotal data point here?
>

​Make that two anecdotal data points :-)​

Any number of things can be described as trivial depending on the
> skillset and patience of the user.  When users report a bug, they are
> not expecting to be asked to download and "untar" stuff.  Not every
> user is a programmer.
>
​
But seriously now, your arguments are also anecdotal. Lets not pretend
we're objective here. That sort of attitude is disingenuous and will
quickly devolve this discussion to mere ad hominems.
​


> It's not trivial, because if you aren't careful you'll be running them
> against the tarball / checkout instead (because of Python munging the
> PYTHONPATH behind your back, for example), and this can go unnoticed for
> a long time.
>

​This is a flaw of the project layout really. If you don't isolate your
sources from the import paths then you're probably testing the wrong way.
In other words, you're probably not testing the installed code. Very few
test runners change the current working directory by default [1], so it's
better to just get a better project layout. pyca/cryptography
 is a good example.​

​[1] trial is the only one that I know of, and it's hardly popular for
testing anything but projects that use Twisted​.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Where should I put tests when packaging python modules?

[Ionel Cristian Mărieș]

On Tue, Oct 6, 2015 at 6:33 PM, Erik Bray <erik.m.b...@gmail.com> wrote:

> ​Okay, though, so maybe if there is nothing to offer here but anecdata
> then maybe we should stop acting like there's "one right way here".  I
> have projects that install their test suite and test dependencies
> because it is frequently useful to ask users to run a self-test (and
> users themselves want to be able to do it for a variety of reasons).
> ​
>
> There are other projects where it doesn't make sense, and those don't
> have to install the tests (I still think in those cases that the tests
> should live in the package instead of outside it, but simply not
> installed).


​To be honest, I like the idea of providing the tests​ in the installed
package. Using the test suite as a debugging/diagnostic tool is obviously
desirable. It's just that it's unpractical for general use. Another
anecdote I know, but humour these two concerns:

* How to deal with dependencies?

** Should we use extras? Installing test deps has the disadvantage of
version conflicts. Unless we make some sort of "virtualenv-for-tests" tool?
** Should we vendor the deps? But isn't that maybe too hard to do (or plain
wrong for other reasons)?
** Should we avoid having deps? That can be too limiting in some
situations, unittest is very bare compared to pytest or nose.

​* What sort of tests should be included? Integration tests are special
case, if they need external services, temporary storage or what not. Would
we then need to have clear separation for different types of tests?

I'm not saying tests inside package is bad at all. But to flaunt it around
as a "best practice" requires at least some recommendations for the two
concerns illustrated above, and probably better tooling.




Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] README.rst vs DESCRIPTION.rst

[Ionel Cristian Mărieș]

On Sun, Sep 27, 2015 at 8:05 PM, Thomas Güttler <
guettl...@thomas-guettler.de> wrote:

>
> OK, the sample project is not the definitive guide line.
> Where can I find the definitive guide line?


​I don't think there can be a "definitive guide line"​. Unlike the core
language the packaging part of Python is a messy soup of different and
often competing ideas, styles and tools.

So you cannot have an definitive or objective guide for something that's
subjective in nature.

About the README vs DESCRIPTION - ask yourself, what would you use README
for then? I believe that's absolutely nothing. You only need one. :-)



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] README.rst vs DESCRIPTION.rst

[Ionel Cristian Mărieș]

On Mon, Sep 28, 2015 at 12:20 AM, Ian Cordasco <graffatcolmin...@gmail.com>
wrote:

> Your project's long description doesn't need
> detailed instructions on how to start contributing, reporting bugs,
> etc.
>

​What would you put in README then?

For contribution/bucktracker guide CONTRIBUTING.rst/md is a better place -
GitHub loves it. But who cares, no one uses GitHub nowdays :)​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Can't re-upload package?

[Ionel Cristian Mărieș]

Yes, you need to make a new release. This is enforced for security purposes
(so you can't swap out code for releases that people deemed safe).

If you don't want to make a patch release (1.2.X) and your change doesn't
change anything functionally you could make a "post release":
https://www.python.org/dev/peps/pep-0440/#post-releases


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Tue, Sep 22, 2015 at 1:29 AM, Bill Deegan <b...@baddogconsulting.com>
wrote:

> Greetings,
>
> I recently uploaded version 2.4.0 of SCons.
> For some reason pip wasn't installing 2.4.0 but was pulling  2.3.6 so I
> figured I'd delete the release and re-upload.
>
> Then I get the following errors:
> Submitting dist/scons-2.4.0.tar.gz to https://pypi.python.org/pypi
> Upload failed (400): This filename has previously been used, you should
> use a different version.
> error: Upload failed (400): This filename has previously been used, you
> should use a different version.
>
> Do I really need to cut a whole new release (to change version #) to
> re-upload to pypi?
>
> -Bill
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] wheel 0.25.0 released with Python 3.5 support

[Ionel Cristian Mărieș]

Hey,

It's still broken on 3.5. Can you merge
https://bitbucket.org/pypa/wheel/pull-requests/59/fix-multi-entrypoint-failure-on-python-3/diff
and make a new release?

Thanks,
-- Ionel Cristian Mărieș,

On Thu, Sep 17, 2015 at 4:23 AM, Daniel Holth <dho...@gmail.com> wrote:

> With Nate's help, I've released wheel 0.25.0, which includes contributions
> from several contributors, and most notably fixes a Python 3.5 issue. Enjoy!
>
> Daniel Holth
>
> ___
> Distutils-SIG maillist  -  Distutils-SIG@python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Python-ideas] PyPI search still broken

[Ionel Cristian Mărieș]

Wouldn't it be better if you'd just build an external search service?
Getting a list of packages and descriptions should be possible no? (just
asking, not 100% sure)

I doubt the maintainers are just going to come out and say "ok, this guy
has waited long enough, lets take his contribution in". If they didn't care
about the search 2.5 years ago why would they care now.

Sorry for being snide here but my impression is that Warehouse could had
been shipped a while ago instead of getting rewritten
​ ​
s
​everal times.​ I'm not saying that's bad, it's just that there's a
mismatch in goals here.


Thanks,
-- Ionel Cristian Mărieș

On Thu, Sep 10, 2015 at 2:01 AM, David Wilson <dw+python-id...@hmmz.org>
wrote:

> Hi there,
>
> My 2.5 year old offer to retrofit the old codebase with a new search
> system still stands[1]. :)  There is no reason for this to be a complex
> affair, the prototype built back then took only a few hours to complete.
>
> No doubt the long term answer is probably "Warehouse fixes this", but
> Warehouse seems no nearer a reality than it did in 2013.
>
>
> David
>
> [1]
> https://groups.google.com/forum/#!search/%22david$20wilson%22$20search$20pypi/pypa-dev/ZjUNkczsKos/2et8926YOQYJ
>
> On Thu, Sep 10, 2015 at 12:35:04AM +0200, Giovanni Cannata wrote:
> > Hi, sorry to bother you again, but the search problem on PyPI is still
> present
> > after different weeks and it's very annoying. I've just released a new
> version
> > of my ldap3 project and it doesn't show up when searching with its name.
> For
> > mine (and I suppose for other emerging project, especially related to
> Python 3)
> > it's vital to be easily found by other developers that use pip and PyPI
> as THE
> > only repository for python packages and using the number of download as a
> > ranking of popularity of a project.
> >
> > If search can't be fixed there should be at least a warning on the PyPI
> > homepage to let users know that search is broken and that using Google
> for
> > searching could help to find more packages.
> >
> > Bye,
> > Giovanni
>
> > ___
> > Python-ideas mailing list
> > python-id...@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> Python-ideas mailing list
> python-id...@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Virtualenv bug breaking tox runs

[Ionel Cristian Mărieș]

You could try using the virtualenv rewrite (my branch) - it's well tested,
albeit unreviewed. AFAIK it doesn't have the issue you've hit.

Just run: pip install
https://github.com/ionelmc/virtualenv/archive/develop.zip




Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Wed, Jul 15, 2015 at 9:08 AM, Marius Gedminas mar...@gedmin.as wrote:

 On Wed, Jul 15, 2015 at 12:55:50AM -0400, Randy Syring wrote:
  I'm trying to use tox from python2 to test a python3 environment. But I
 get
  an exception like the following:
 
  rsyring@loftex:~/projects/blaze/blazeutils-src$ python -m virtualenv
  --python python3 ~/tmp/testvenv
  Running virtualenv with interpreter /home/rsyring/bin/python3
  Traceback (most recent call last):
File /usr/local/lib/python2.7/dist-packages/virtualenv.py, line 14,
 in
  module
  import shutil
File /opt/python34/lib/python3.4/shutil.py, line 11, in module
  import fnmatch
File /opt/python34/lib/python3.4/fnmatch.py, line 15, in module
  import functools
File /opt/python34/lib/python3.4/functools.py, line 21, in module
  from collections import namedtuple
File /opt/python34/lib/python3.4/collections/__init__.py, line 17,
 in
  module
  from reprlib import recursive_repr as _recursive_repr
File /usr/local/lib/python2.7/dist-packages/reprlib.py, line 3, in
  module
  from repr import *
  ImportError: No module named 'repr'
 
  There is a bug for this in virtualenv:
 
  https://github.com/pypa/virtualenv/issues/625
 
  So, I realize I could use `python3 -m virtualenv` if I was running the
  command myself.  But, tox is making the call to virtualenv.
 
  This was working the last time I tested it but has now broken.  I'm
 guessing
  that is because I upgraded tox or virtualenv?

 It broke now because you 'sudo pip install'ed something that depends on
 something that ships /usr/local/lib/python2.7/dist-packages/reprlib.py
 (which probably comes from pies2overrides)

  Any pointers welcome as to the best way to resolve this issue now?

 I would recommend sudo pip uninstall pies2overrides (and whatever
 depended on it).  A good way to avoid pain is to never ever 'sudo pip
 install' stuff.

 A different workaround would be to create a clean virtualenv, install
 tox into it, then run tox from that virtualenv.

 Marius Gedminas
 --
 Un*x admins know what they are doing by definition.
 -- Bernd Petrovitsch

 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] 400 Client Error: Binary wheel for an unsupported platform

[Ionel Cristian Mărieș]

Would be quite useful to see some references and details about the vague
issues being mentioned in the thread. It would help a lot the less versed
engineers (like me) understand the issues at hand (and hopefully reduce the
amount of disagreement overall).

For example, for me it's not clear what's wrong with Antoine's proposal
(compile on Centos 5) - it seemed quite sensible approach to produce a
reasonably compatible binary.

Some issues with kernel ABI have been mentioned - can anyone point me to
some resources describing the possible problems? Is it correct to assume
that it's about using vendor-specific kernel api?

Also, what does Conda do to solve the binary compatibility issues and
distutils or pip could never ever do (or implement)?

Thanks,
-- Ionel Cristian Mărieș

On Thu, Jul 9, 2015 at 4:50 PM, Nick Coghlan ncogh...@gmail.com wrote:

 On 9 July 2015 at 05:06, Antoine Pitrou solip...@pitrou.net wrote:
  On Wed, 08 Jul 2015 13:05:45 -0400
  Tres Seaver tsea...@palladion.com wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  On 07/08/2015 07:10 AM, Antoine Pitrou wrote:
 
   Seriously, how this is even supposed to be relevant? The whole point
   is to produce best-effort packages that work on still-supported
   mainstream distros, not any arbitrary Linux setup.
 
  I'm arguing that allowing PyPI uploads of binary wheels for Linux will
 be
  actively harmful.
 
  There is no point in reinstating an argument that has already been made
  and discussed in the other subthread (of course, you would have to read
  it first to know that).

 Steady on folks - prebuilt binary software distribution is *really*,
 *really*, hard, and we're not going to magically solve problems in a
 couple of days that have eluded Linux distribution vendors for over a
 decade. Yes, it's annoying, yes, it's frustrating, but sniping at each
 other when we point out the many and varied reasons it's hard won't
 help us to improve the experience for Python users.

 The key is remembering that now matter how broken you think prebuilt
 binary software distribution might be, it's actually worse. And
 channeling Hofstadter's Law: this principle remains true, even when
 you attempt to take this principle into account :)

 If you look at various prebuilt binary ecosystems to date, there's
 either a central authority defining the ABI to link against:

 - CPython on Windows
 - CPython on Mac OS X
 - Linux distributions with centralised package review and build systems
 - conda
 - nix
 - MS Visual Studio
 - XCode
 - Google Play
 - Apple App Store

 Or else a relatively tightly controlled isolation layer between the
 application code and the host system:

 - JVM
 - .NET CLR

 (even Linux containers can still hit the kernel ABI compatibility
 issues mentioned elsewhere in the thread)

 As Donald notes, I think we're now in a good position to start making
 progress here, but the first step is going to be finding a way to
 ensure that *by default*, pip on Linux ignores wheel files published
 on PyPI, and requires that they be *whitelisted* in some fashion
 (whether individually or categorically). That way, we know we're not
 going to make the default user experience on Linux *worse* than the
 status quo while we're still experimenting with how we want the
 publication side of things to work. Debugging build time API
 compatibility errors can be hard enough, debugging runtime A*B*I
 compatibility errors is a nightmare even for seasoned support
 engineers.

 It seems to me that one possible way to do that might be to change
 PyPI from whitelisting Windows and Mac OS X (as I believe it does now)
 to instead blacklisting all the other currently possible results from
 distutils.util.get_platform().

 Regards,
 Nick.

 --
 Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 https://mail.python.org/mailman/listinfo/distutils-sig

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Secondary package indexes

[Ionel Cristian Mărieș]

Hello,

Probably this has been discussed in the past but I'm asking anyway cause
I'm not sure what's it at now.

Currently there's this problem with wheels, many package authors don't
publish them for the platforms I'm using. I'm speaking about the wheels
that need a compiler and/or other annoying dependencies.

It would be really nice if one could configure pip to look into a secondary
(external) indexes. This way someone could make his own index with windows
wheels, another person could make an index with wheels for ubuntu 14.04 and
people can use those to avoid the pain of compiling the packages.

This is already popular, eg: http://www.lfd.uci.edu/~gohlke/pythonlibs/ but
not readily usable with pip.

Maybe PyPI could even provide hosting for these 3rd party wheels, this
would make publishing very easy and lower the entry bar.

I believe we'll never get package authors to publish wheels for platforms
they don't care about. But other people might - we just need to make this
easy and convenient.

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Secondary package indexes

[Ionel Cristian Mărieș]

On Sun, Apr 19, 2015 at 4:10 PM, Paul Moore p.f.mo...@gmail.com wrote:

 you can add an
 extra_index_url to your pip.ini


​Would this work as expected if a package is in multiple indexes? Eg: sdist
in main index, wheel in ​extra index.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Secondary package indexes

[Ionel Cristian Mărieș]

So what you're saying is that Christoph Gohlke could use binstar to host
the wheels yes?


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Sun, Apr 19, 2015 at 4:10 PM, Paul Moore p.f.mo...@gmail.com wrote:

 On 19 April 2015 at 14:00, Ionel Cristian Mărieș cont...@ionelmc.ro
 wrote:
  Probably this has been discussed in the past but I'm asking anyway cause
 I'm
  not sure what's it at now.
 
  Currently there's this problem with wheels, many package authors don't
  publish them for the platforms I'm using. I'm speaking about the wheels
 that
  need a compiler and/or other annoying dependencies.
 
  It would be really nice if one could configure pip to look into a
 secondary
  (external) indexes. This way someone could make his own index with
 windows
  wheels, another person could make an index with wheels for ubuntu 14.04
 and
  people can use those to avoid the pain of compiling the packages.
 
  This is already popular, eg: http://www.lfd.uci.edu/~gohlke/pythonlibs/
 but
  not readily usable with pip.
 
  Maybe PyPI could even provide hosting for these 3rd party wheels, this
 would
  make publishing very easy and lower the entry bar.
 
  I believe we'll never get package authors to publish wheels for platforms
  they don't care about. But other people might - we just need to make this
  easy and convenient.

 I'm not sure exactly what you're suggesting here, but you can add an
 extra_index_url to your pip.ini. As far as hosting is concerned, if
 you don't want to set up your own package index, binstar offers
 pypi-style hosting for wheels. I'm not sure what reasons there may be
 for Christoph Gohlke not hosting his wheels in a pip-usable format. It
 may be worth someone asking him. I know it'd be nicer for me to point
 to his index, rather than downloading the wheels I need and hosting
 them myself for my personal use.

 Paul

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] buildout/setuptools slow as it scans the whole project dir

[Ionel Cristian Mărieș]

Could this be the same problem
https://bitbucket.org/pypa/setuptools/issue/249/have-a-way-to-ingore-specific-dirs-when
?

I frequently have this issue (.tox dir can sometimes get quite large) and I
resorted to monkeypatching setuptools (I know, right?) in
~/.local/lib/python2.7/site-packages/usercustomize.py:

import setuptools
from distutils import filelist
import os
def findall(dir=os.curdir, original=filelist.findall, listdir=os.listdir,
basename=os.path.basename):
os.listdir = lambda path: [i for i in listdir(path) if '/.tox/' not in
i and not i.startswith('.tox/')]
try:
return original(dir)
finally:
os.listdir = listdir
filelist.findall = findall



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Wed, Apr 15, 2015 at 5:01 PM, Reinout van Rees rein...@vanrees.org
wrote:

 Hi,

 In some of my projects, buildout takes a looong time to complete.
 Sometimes the same problem occurs on the server or on another developer's
 laptop, sometimes not. The difference is something like 15 seconds if
 there's no problem and 5 minutes if the problem occurs.

 It is terribly hard to pinpoint the exact problem and/or cause. An error
 in the setup.py or or MANIFEST.in is unlikely, as the very same project
 might take 5 minutes locally and 15 seconds on the server or vice versa...

 Anyway, if I run bin/buildout as strace -f bin/buildout, I see a lot
 of stat calls. Setuptools walks through all the files inside my project
 dir. Including parts/omelette/* and, if available, a bower_compontents/
 directory full of thousands of javascript files. Removing some of these
 directories (which running the buildout re-creates) fixes the speed issue
 for one run.

 I modified my local buildout copy to run setup.py develop with a -v
 instead of a -q option. This way I found out where it approximately happens:


 /usr/bin/python /tmp/tmp6UdsMl -v develop -mxN -d
 /vagrant/sso/develop-eggs/tmpfioc1Ibuild
 running develop
 running egg_info
 writing requirements to sso.egg-info/requires.txt
 writing sso.egg-info/PKG-INFO
 writing top-level names to sso.egg-info/top_level.txt
 writing dependency_links to sso.egg-info/dependency_links.txt
 writing entry points to sso.egg-info/entry_points.txt

 ### This is where the process seems to stop a couple of minutes to scan
 all the files.

 reading manifest file 'sso.egg-info/SOURCES.txt'
 reading manifest template 'MANIFEST.in'
 writing manifest file 'sso.egg-info/SOURCES.txt'
 running build_ext
 Creating /vagrant/sso/develop-eggs/tmpfioc1Ibuild/sso.egg-link (link to .)



 The MANIFEST.in loooks like this:

 # Include docs in the root.
 include *.rst
 # Include everything in our project directory (sso/views.py,
 sso/static/some.js, etc)
 graft sso


 It is a git project. The setup.py looks like this:


 from setuptools import setup

 version = '1.1.dev0'

 long_description = '\n\n'.join([
 open('README.rst').read(),
 open('CREDITS.rst').read(),
 open('CHANGES.rst').read(),
 ])

 install_requires = [
 'Django = 1.4.2,  1.7',
 'django-nose',
 'lizard-auth-server',
 'gunicorn',
 'raven',
 'werkzeug',
 'south',
 'django-auth-ldap',
 'django-mama-cas',
 ],

 setup(name='sso',
   version=version,
   description=Single sign on server (and more) for lizard,
   long_description=long_description,
   # Get strings from http://www.python.org/pypi?%
 3Aaction=list_classifiers
   classifiers=['Programming Language :: Python',
'Framework :: Django',
],
   keywords=[],
   author='Do not blame Reinout',
   author_email='reinout.vanr...@nelen-schuurmans.nl',
   url='',
   license='GPL',
   packages=['sso'],
   zip_safe=False,
   install_requires=install_requires,
   entry_points={
   'console_scripts': [
   ]},
   )



 Conclusion for me: something somewhere in setuptools is reading my whole
 project folder. It does it after writing entry points to
 sso.egg-info/entry_points.txt and before reading manifest file
 'sso.egg-info/SOURCES.txt'. The SOURCES.txt itself is small:


 CHANGES.rst
 CREDITS.rst
 LICENSE.rst
 MANIFEST.in
 README.rst
 setup.cfg
 setup.py
 sso/__init__.py
 sso/__init__.pyc
 sso/admin.py
 sso/developmentsettings.py
 sso/developmentsettings.pyc
 sso/models.py
 sso/models.pyc
 sso/settings.py
 sso/settings.pyc
 sso/stagingsettings.py
 sso/tests.py
 sso/urls.py
 sso/views.py
 sso.egg-info/PKG-INFO
 sso.egg-info/SOURCES.txt
 sso.egg-info/dependency_links.txt
 sso.egg-info/entry_points.txt
 sso.egg-info/not-zip-safe
 sso.egg-info/requires.txt


 Hm. I see some .pyc files in there. Something that needs fixing, but not
 the cause, I think.

 Is there something I'm missing? Where should I look? I cannot find
 writing entry points to... in the setuptools source code right away.



 Reinout

 --
 Reinout van Rees  http://reinout.vanrees.org/
 rein...@vanrees.org

Re: [Distutils] Method for calculating .so file names

[Ionel Cristian Mărieș]

distutils.sysconfig.get_config_vars(SO) or
distutils.sysconfig.get_config_vars(EXT_SUFFIX)

(seems the later is only available for py3? and the py3 source say SO is
deprecated)

Mind you, this is easy to find out if you build an extension and you use
hunter https://pypi.python.org/pypi/hunter, that's how I found it ;-)


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Wed, Apr 8, 2015 at 1:28 AM, Randy Syring ra...@thesyrings.us wrote:

  As a follow-up to my earlier question, is there a way to pragmatically
 determine the naming scheme of installed shared object files?  I've seen a
 couple different naming formats:

 # python 2.7.6 - default ubuntu version
 $ ls /usr/lib/python2.7/dist-packages/_dbus_*
 /usr/lib/python2.7/dist-packages/_dbus_bindings.so
 /usr/lib/python2.7/dist-packages/_dbus_glib_bindings.so

 # python 3.4.0 - default ubuntu version
 $ ls /usr/lib/python3/dist-packages/_dbus_*
 /usr/lib/python3/dist-packages/_
 dbus_bindings.cpython-34m-x86_64-linux-gnu.so
 /usr/lib/python3/dist-packages/_
 dbus_glib_bindings.cpython-34m-x86_64-linux-gnu.so

 # python 3.4.3 - manual install on ubuntu
 $ ls /opt/python34/lib/python3.4/site-packages/_dbus_*
 /opt/python34/lib/python3.4/site-packages/_dbus_bindings.so
 /opt/python34/lib/python3.4/site-packages/_dbus_glib_bindings.so


 I can piece together the file structure for 3.4.0 from information in
 sysconfig, but I'm wondering if there is a better way.

 Thanks.


 *Randy Syring*
 Husband | Father | Redeemed Sinner


 *For what does it profit a man to gain the whole world and forfeit his
 soul? (Mark 8:36 ESV)*


 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] installing package - problems

[Ionel Cristian Mărieș]

Hello,

It looks like you need to install the compiler. If you want to install it,
I have a guide for that here
http://blog.ionelmc.ro/2014/12/21/compiling-python-extensions-on-windows/#for-python-3-4
(well, what worked for me - you might need additional stuff for pysftp).
Give it a try.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Wed, Apr 8, 2015 at 4:29 PM, Leung, Edward edward_le...@invesco.com
wrote:

  Dear Sir/Madam,



 I was trying to install a python package pysftp using the following at
 command prompt: python –m pip install pysftp and I got the following error.
 Could you tell me what is not working?? Thanks.





 copying lib\Crypto\Random\Fortuna\FortunaGenerator.py -
 build\lib.win-amd64

 -3.4\Crypto\Random\Fortuna



 copying lib\Crypto\Random\Fortuna\SHAd256.py -
 build\lib.win-amd64-3.4\Cryp

 to\Random\Fortuna



 copying lib\Crypto\Random\Fortuna\__init__.py -
 build\lib.win-amd64-3.4\Cry

 pto\Random\Fortuna



 creating build\lib.win-amd64-3.4\Crypto\Random\OSRNG



 copying lib\Crypto\Random\OSRNG\fallback.py -
 build\lib.win-amd64-3.4\Crypt

 o\Random\OSRNG



 copying lib\Crypto\Random\OSRNG\nt.py -
 build\lib.win-amd64-3.4\Crypto\Rand

 om\OSRNG



 copying lib\Crypto\Random\OSRNG\posix.py -
 build\lib.win-amd64-3.4\Crypto\R

 andom\OSRNG



 copying lib\Crypto\Random\OSRNG\rng_base.py -
 build\lib.win-amd64-3.4\Crypt

 o\Random\OSRNG



 copying lib\Crypto\Random\OSRNG\__init__.py -
 build\lib.win-amd64-3.4\Crypt

 o\Random\OSRNG



 creating build\lib.win-amd64-3.4\Crypto\SelfTest



 copying lib\Crypto\SelfTest\st_common.py -
 build\lib.win-amd64-3.4\Crypto\S

 elfTest



 copying lib\Crypto\SelfTest\__init__.py -
 build\lib.win-amd64-3.4\Crypto\Se

 lfTest



 creating build\lib.win-amd64-3.4\Crypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\common.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_AES.py -
 build\lib.win-amd64-3.4\Cr

 ypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_ARC2.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_ARC4.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_Blowfish.py -
 build\lib.win-amd64-3

 .4\Crypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_CAST.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_DES.py -
 build\lib.win-amd64-3.4\Cr

 ypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_DES3.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_pkcs1_15.py -
 build\lib.win-amd64-3

 .4\Crypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_pkcs1_oaep.py -
 build\lib.win-amd64

 -3.4\Crypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_XOR.py -
 build\lib.win-amd64-3.4\Cr

 ypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\__init__.py -
 build\lib.win-amd64-3.4\Cr

 ypto\SelfTest\Cipher



 creating build\lib.win-amd64-3.4\Crypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\common.py -
 build\lib.win-amd64-3.4\Crypto

 \SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_HMAC.py -
 build\lib.win-amd64-3.4\Cry

 pto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_MD2.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_MD4.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_MD5.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_RIPEMD.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_SHA.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_SHA224.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_SHA256.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_SHA384.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_SHA512.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\__init__.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Hash



 creating build\lib.win-amd64-3.4\Crypto\SelfTest\Protocol



   copying lib\Crypto\SelfTest\Protocol\test_AllOrNothing.py -
 build\lib.win-a

 md64-3.4\Crypto\SelfTest\Protocol



 copying lib\Crypto\SelfTest\Protocol\test_chaffing.py -
 build\lib.win-amd64

 -3.4\Crypto\SelfTest\Protocol



 copying lib\Crypto\SelfTest\Protocol\test_KDF.py -
 build\lib.win-amd64-3.4\

 Crypto\SelfTest\Protocol



 copying lib\Crypto\SelfTest\Protocol\test_rfc1751.py -
 build\lib.win-amd64-

 3.4\Crypto

Re: [Distutils] installing package - problems

[Ionel Cristian Mărieș]

Yes, that's what worked for me. If you feel adventurous you can try Victor
Stinner's SDK-only approach (mentioned at the end).


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Wed, Apr 8, 2015 at 5:36 PM, Leung, Edward edward_le...@invesco.com
wrote:

  Thanks…..so for the 64bit, I will need to install BOTH Visual C++ 2020
 Express and Windows SDK for Visual Studio 2010??



 edward



 *From:* Ionel Cristian Mărieș [mailto:cont...@ionelmc.ro]
 *Sent:* Wednesday, April 08, 2015 10:30 AM
 *To:* Leung, Edward
 *Cc:* distutils-sig@python.org; D'Amore, Robert M.; Waisburd, Andrew;
 Bithoney, Anthony S
 *Subject:* Re: [Distutils] installing package - problems



 Hello,

 It looks like you need to install the compiler. If you want to install it,
 I have a guide for that here
 http://blog.ionelmc.ro/2014/12/21/compiling-python-extensions-on-windows/#for-python-3-4
 (well, what worked for me - you might need additional stuff for pysftp).
 Give it a try.



 Thanks,
 -- Ionel Cristian Mărieș, http://blog.ionelmc.ro



 On Wed, Apr 8, 2015 at 4:29 PM, Leung, Edward edward_le...@invesco.com
 wrote:

 Dear Sir/Madam,



 I was trying to install a python package pysftp using the following at
 command prompt: python –m pip install pysftp and I got the following error.
 Could you tell me what is not working?? Thanks.





 copying lib\Crypto\Random\Fortuna\FortunaGenerator.py -
 build\lib.win-amd64

 -3.4\Crypto\Random\Fortuna



 copying lib\Crypto\Random\Fortuna\SHAd256.py -
 build\lib.win-amd64-3.4\Cryp

 to\Random\Fortuna



 copying lib\Crypto\Random\Fortuna\__init__.py -
 build\lib.win-amd64-3.4\Cry

 pto\Random\Fortuna



 creating build\lib.win-amd64-3.4\Crypto\Random\OSRNG



 copying lib\Crypto\Random\OSRNG\fallback.py -
 build\lib.win-amd64-3.4\Crypt

 o\Random\OSRNG



 copying lib\Crypto\Random\OSRNG\nt.py -
 build\lib.win-amd64-3.4\Crypto\Rand

 om\OSRNG



 copying lib\Crypto\Random\OSRNG\posix.py -
 build\lib.win-amd64-3.4\Crypto\R

 andom\OSRNG



 copying lib\Crypto\Random\OSRNG\rng_base.py -
 build\lib.win-amd64-3.4\Crypt

 o\Random\OSRNG



 copying lib\Crypto\Random\OSRNG\__init__.py -
 build\lib.win-amd64-3.4\Crypt

 o\Random\OSRNG



 creating build\lib.win-amd64-3.4\Crypto\SelfTest



 copying lib\Crypto\SelfTest\st_common.py -
 build\lib.win-amd64-3.4\Crypto\S

 elfTest



 copying lib\Crypto\SelfTest\__init__.py -
 build\lib.win-amd64-3.4\Crypto\Se

 lfTest



 creating build\lib.win-amd64-3.4\Crypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\common.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_AES.py -
 build\lib.win-amd64-3.4\Cr

 ypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_ARC2.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_ARC4.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_Blowfish.py -
 build\lib.win-amd64-3

 .4\Crypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_CAST.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_DES.py -
 build\lib.win-amd64-3.4\Cr

 ypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_DES3.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_pkcs1_15.py -
 build\lib.win-amd64-3

 .4\Crypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_pkcs1_oaep.py -
 build\lib.win-amd64

 -3.4\Crypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\test_XOR.py -
 build\lib.win-amd64-3.4\Cr

 ypto\SelfTest\Cipher



 copying lib\Crypto\SelfTest\Cipher\__init__.py -
 build\lib.win-amd64-3.4\Cr

 ypto\SelfTest\Cipher



 creating build\lib.win-amd64-3.4\Crypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\common.py -
 build\lib.win-amd64-3.4\Crypto

 \SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_HMAC.py -
 build\lib.win-amd64-3.4\Cry

 pto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_MD2.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_MD4.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_MD5.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_RIPEMD.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_SHA.py -
 build\lib.win-amd64-3.4\Cryp

 to\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_SHA224.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_SHA256.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Hash



 copying lib\Crypto\SelfTest\Hash\test_SHA384.py -
 build\lib.win-amd64-3.4\C

 rypto\SelfTest\Hash



 copying lib\Crypto

Re: [Distutils] Method for calculating virtualenv site-packages directory

[Ionel Cristian Mărieș]

As far as I know, distutils.sysconfig.get_python_lib() is the standard way
of doing it (and that's what tools use).


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Tue, Apr 7, 2015 at 5:14 PM, Randy Syring ra...@thesyrings.us wrote:

  If I'm running a python script in a virtualenv, what is the best method
 for calculating the path of that virtualenv's site-packages directory?

 I'm only running this command for development environments and as a
 shortcut for developers, so something that works most of the time is fine.
 This code isn't going to end up in a production system anywhere.

 *Randy Syring*
 Husband | Father | Redeemed Sinner


 *For what does it profit a man to gain the whole world and forfeit his
 soul? (Mark 8:36 ESV)*


 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Question about wheels and python-dbg 2.7

[Ionel Cristian Mărieș]

Hey,

It appears that using a debug build of python 2.7 doesn't mark the wheels
built using it in any special way. Pip would install them on a regular
python 2.7 (if they would be on an package index) and then later on imports
for C extensions would fail (not sure why, tho I suspect the different
_d.so naming scheme).

Is there something more complicated preventing this be fixed or there's
just hasn't been enough interest? Why does the import fail anyway?

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] it's happened - wheels without sdists (flit)

[Ionel Cristian Mărieș]

On Mon, Mar 30, 2015 at 6:05 PM, Ian Cordasco graffatcolmin...@gmail.com
wrote:

 In other words, no one should read the docs because that's a waste of
 time? Because a lot of time has been poured into the packaging docs and if
 they're not sufficient, then instead of improving them, people should write
 undocumented tools that force people to read the source? I'm not sure how
 that's better than what we already have.


​A waste of time? No. But it sure is poor investment of time for newbie
users. It's a futile struggle to document (or read about) all the features
of distutils and setuptools, not because it can't be documented, but
because there's too much ground to cover and PyPA's packaging.python.org
approach is to ​just give an overview of what's available and avoid giving
any real best practice recommendations as much as possible. There may be
good reasons for that but that's not a sensible approach to giving users a
pitfall free learning path.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] it's happened - wheels without sdists (flit)

[Ionel Cristian Mărieș]

On Mon, Mar 30, 2015 at 6:39 PM, Xavier Fernandez xav.fernan...@gmail.com
wrote:

 I think the point was not to say that documentation is useless (and there
 is some: http://flit.readthedocs.org/en/latest/ ) but that the
 code/implementation is much simpler than the combination of
 distutils/setuptools/bdist_wheel.

 On Mon, Mar 30, 2015 at 5:26 PM, Ian Cordasco graffatcolmin...@gmail.com
 wrote:


 So for new python programmers (or newbie users in general) reading the
 entire source of another package to understand it is a better experience?

 ​
​To put that in context, flit goes for less than 600 SLOC while
distutils+setuptools+wheel amount to​ over 2 SLOC. At that ratio
arguments for distutils+setuptools+wheel documentation seem unreasonable.

​
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] it's happened - wheels without sdists (flit)

[Ionel Cristian Mărieș]

On Mon, Mar 30, 2015 at 6:55 PM, Ian Cordasco graffatcolmin...@gmail.com
wrote:

 Then, when the new user goes to publish it, there's tons of prior
 documentation on how to do it. If they run into problems using flit they
 have the skimpy documentation or the source.


​Now it might have skimpy docs and no users, but that's largely a product
of time. I think `flit` should be judged on what it can be in the future,
not all what it's right now. To put it in picture, the argument you're
making is like comparing the amazon rainforest to a banana milkshake
recipe.​



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Installing a file into sitepackages

[Ionel Cristian Mărieș]

Also, a similar command subclass can be written for `develop`. So far i got
3 subclasses, for: build, easy_install and develop. Did I miss something
important?


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Wed, Mar 25, 2015 at 2:51 PM, Stuart Axon stua...@yahoo.com wrote:

 That looks much cleaner than my one, I'll give it a try..  does it work on
 python3, just found out my one does not.

 S++



   On Wednesday, March 25, 2015 9:03 AM, Ionel Cristian Mărieș 
 cont...@ionelmc.ro wrote:



 This seems to do the trick:

 class EasyInstallWithPTH(easy_install):
 def run(self):
 easy_install.run(self)
 for path in glob(join(dirname(__file__), 'src', '*.pth')):
 dest = join(self.install_dir, basename(path))
 self.copy_file(path, dest)


 Thanks,
 -- Ionel Cristian Mărieș, http://blog.ionelmc.ro

 On Tue, Mar 24, 2015 at 11:36 AM, Stuart Axon stua...@yahoo.com wrote:

 Hi,
  This works from pypi - but not when installing from source with  python
 setup.py install  which stops this nifty thing from working:

 PYTHON_HUNTER=module='os.path' python yourapp.py


 Sandbox monkeypatches os.file, so I think it catches you using copy.
 Maybe we need a common API for code that runs at startup?

 S++



   On Tuesday, March 24, 2015 3:56 PM, Ionel Cristian Mărieș 
 cont...@ionelmc.ro wrote:



 Hey,

 If you just want to copy a out-of-package file into site-package you could
 just override the build command and copy it there (in the build dir).
 Here's an example:
 https://github.com/ionelmc/python-hunter/blob/master/setup.py#L27-L31 -
 it seems to work fine with wheels.



 Thanks,
 -- Ionel Cristian Mărieș, http://blog.ionelmc.ro

 On Mon, Mar 16, 2015 at 11:02 AM, Stuart Axon stua...@yahoo.com wrote:

 Hi All
 This, and another memory-leak bug were triggered by the sandbox.
 Would it be possible to either add an API to exempt files, or just allow
 writing within site packages, even if just for .pth files ?

 I'm monkey patching around these for now
 https://github.com/stuaxo/vext/blob/master/setup.py#L16

 S++



   On Thursday, March 12, 2015 2:54 PM, Stuart Axon stua...@yahoo.com
 wrote:



 For closure:  The solution was to make a Command class + implement
 finalize_options to fixup the paths in distribution.data_files.


 Source:

 # https://gist.github.com/stuaxo/c76a042cb7aa6e77285b
 
 Install a file into the root of sitepackages on windows as well as linux.

 Under normal operation on win32 path_to_site_packages
 gets changed to '' which installs inside the .egg instead.
 

 import os

 from distutils import sysconfig
 from distutils.command.install_data import install_data
 from setuptools import setup

 here = os.path.normpath(os.path.abspath(os.path.dirname(__file__)))

 site_packages_path = sysconfig.get_python_lib()
 site_packages_files = ['TEST_FILE.TXT']

 class _install_data(install_data):
 def finalize_options(self):
 
 On win32 the files here are changed to '' which
 ends up inside the .egg, change this back to the
 absolute path.
 
 install_data.finalize_options(self)
 global site_packages_files
 for i, f in enumerate(list(self.distribution.data_files)):
 if not isinstance(f, basestring):
 folder, files = f
 if files == site_packages_files:
 # Replace with absolute path version
 self.distribution.data_files[i] = (site_packages_path,
 files)

 setup(
 cmdclass={'install_data': _install_data},
 name='test_install',
 version='0.0.1',

 description='',
 long_description='',
 url='https://example.com',
 author='Stuart Axon',
 author_email='stua...@yahoo.com',
 license='PD',
 classifiers=[],
 keywords='',
 packages=[],

 install_requires=[],

 data_files=[
 (site_packages_path, site_packages_files),
 ],

 )



 On Tue, 10 Mar, 2015 at 11:29 PM, Stuart Axon stua...@yahoo.com wrote:

 I had more of a dig into this, with a minimal setup.py:
 https://gist.github.com/stuaxo/c76a042cb7aa6e77285b setup calls
 install_data On win32 setup.py calls install_data which copies the file
 into the egg - even though I have given the absolute path to sitepackages
 C:\ python setup.py install  running install_data creating
 build\bdist.win32\egg copying TEST_FILE.TXT - build\bdist.win32\egg\ 
 On Linux the file is copied to the right path: $ python setup.py install
 . installing package data to build/bdist.linux-x86_64/egg running
 install_data copying TEST_FILE.TXT -
 /mnt/data/home/stu/.virtualenvs/tmpv/lib/python2.7/site-packages 
 *something* is normalising my absolute path to site packages into just '' -
 it's possible to see by looking at self.data_files in the 'run' function
 in: distutils/command/install_data.py - on windows it the first part has
 been changed to '' unlike on linux where it's the absolute path I set

Re: [Distutils] Installing a file into sitepackages

[Ionel Cristian Mărieș]

H, good catch. It appears that when `setup.py install` is used the .pth
file is there, but it's inside the egg (wrong place).


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Tue, Mar 24, 2015 at 11:36 AM, Stuart Axon stua...@yahoo.com wrote:

 Hi,
  This works from pypi - but not when installing from source with  python
 setup.py install  which stops this nifty thing from working:

 PYTHON_HUNTER=module='os.path' python yourapp.py


 Sandbox monkeypatches os.file, so I think it catches you using copy.
 Maybe we need a common API for code that runs at startup?

 S++



   On Tuesday, March 24, 2015 3:56 PM, Ionel Cristian Mărieș 
 cont...@ionelmc.ro wrote:



 Hey,

 If you just want to copy a out-of-package file into site-package you could
 just override the build command and copy it there (in the build dir).
 Here's an example:
 https://github.com/ionelmc/python-hunter/blob/master/setup.py#L27-L31 -
 it seems to work fine with wheels.



 Thanks,
 -- Ionel Cristian Mărieș, http://blog.ionelmc.ro

 On Mon, Mar 16, 2015 at 11:02 AM, Stuart Axon stua...@yahoo.com wrote:

 Hi All
 This, and another memory-leak bug were triggered by the sandbox.
 Would it be possible to either add an API to exempt files, or just allow
 writing within site packages, even if just for .pth files ?

 I'm monkey patching around these for now
 https://github.com/stuaxo/vext/blob/master/setup.py#L16

 S++



   On Thursday, March 12, 2015 2:54 PM, Stuart Axon stua...@yahoo.com
 wrote:



 For closure:  The solution was to make a Command class + implement
 finalize_options to fixup the paths in distribution.data_files.


 Source:

 # https://gist.github.com/stuaxo/c76a042cb7aa6e77285b
 
 Install a file into the root of sitepackages on windows as well as linux.

 Under normal operation on win32 path_to_site_packages
 gets changed to '' which installs inside the .egg instead.
 

 import os

 from distutils import sysconfig
 from distutils.command.install_data import install_data
 from setuptools import setup

 here = os.path.normpath(os.path.abspath(os.path.dirname(__file__)))

 site_packages_path = sysconfig.get_python_lib()
 site_packages_files = ['TEST_FILE.TXT']

 class _install_data(install_data):
 def finalize_options(self):
 
 On win32 the files here are changed to '' which
 ends up inside the .egg, change this back to the
 absolute path.
 
 install_data.finalize_options(self)
 global site_packages_files
 for i, f in enumerate(list(self.distribution.data_files)):
 if not isinstance(f, basestring):
 folder, files = f
 if files == site_packages_files:
 # Replace with absolute path version
 self.distribution.data_files[i] = (site_packages_path,
 files)

 setup(
 cmdclass={'install_data': _install_data},
 name='test_install',
 version='0.0.1',

 description='',
 long_description='',
 url='https://example.com',
 author='Stuart Axon',
 author_email='stua...@yahoo.com',
 license='PD',
 classifiers=[],
 keywords='',
 packages=[],

 install_requires=[],

 data_files=[
 (site_packages_path, site_packages_files),
 ],

 )



 On Tue, 10 Mar, 2015 at 11:29 PM, Stuart Axon stua...@yahoo.com wrote:

 I had more of a dig into this, with a minimal setup.py:
 https://gist.github.com/stuaxo/c76a042cb7aa6e77285b setup calls
 install_data On win32 setup.py calls install_data which copies the file
 into the egg - even though I have given the absolute path to sitepackages
 C:\ python setup.py install  running install_data creating
 build\bdist.win32\egg copying TEST_FILE.TXT - build\bdist.win32\egg\ 
 On Linux the file is copied to the right path: $ python setup.py install
 . installing package data to build/bdist.linux-x86_64/egg running
 install_data copying TEST_FILE.TXT -
 /mnt/data/home/stu/.virtualenvs/tmpv/lib/python2.7/site-packages 
 *something* is normalising my absolute path to site packages into just '' -
 it's possible to see by looking at self.data_files in the 'run' function
 in: distutils/command/install_data.py - on windows it the first part has
 been changed to '' unlike on linux where it's the absolute path I set...
 still not sure where it's happening though. *This all took a while, as
 rebuilt VM and verified on 2.7.8 and 2.7.9.. S++

 On Monday, March 9, 2015 12:17 AM, Stuart Axon stua...@yahoo.com wrote:
  I had a further look - and on windows the file ends up inside the .egg
 file, on linux it ends up inside the site packages as intended. At a guess
 it seems like there might be a bug in the path handling on windows. .. I
 wonder if it's something like this
 http://stackoverflow.com/questions/4579908/cross-platform-splitting-of-path-in-python
 which seems an easy way to get an off-by-one error in a path ?




 ___
 Distutils-SIG

Re: [Distutils] Installing a file into sitepackages

[Ionel Cristian Mărieș]

This seems to do the trick:

class EasyInstallWithPTH(easy_install):
def run(self):
easy_install.run(self)
for path in glob(join(dirname(__file__), 'src', '*.pth')):
dest = join(self.install_dir, basename(path))
self.copy_file(path, dest)


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Tue, Mar 24, 2015 at 11:36 AM, Stuart Axon stua...@yahoo.com wrote:

 Hi,
  This works from pypi - but not when installing from source with  python
 setup.py install  which stops this nifty thing from working:

 PYTHON_HUNTER=module='os.path' python yourapp.py


 Sandbox monkeypatches os.file, so I think it catches you using copy.
 Maybe we need a common API for code that runs at startup?

 S++



   On Tuesday, March 24, 2015 3:56 PM, Ionel Cristian Mărieș 
 cont...@ionelmc.ro wrote:



 Hey,

 If you just want to copy a out-of-package file into site-package you could
 just override the build command and copy it there (in the build dir).
 Here's an example:
 https://github.com/ionelmc/python-hunter/blob/master/setup.py#L27-L31 -
 it seems to work fine with wheels.



 Thanks,
 -- Ionel Cristian Mărieș, http://blog.ionelmc.ro

 On Mon, Mar 16, 2015 at 11:02 AM, Stuart Axon stua...@yahoo.com wrote:

 Hi All
 This, and another memory-leak bug were triggered by the sandbox.
 Would it be possible to either add an API to exempt files, or just allow
 writing within site packages, even if just for .pth files ?

 I'm monkey patching around these for now
 https://github.com/stuaxo/vext/blob/master/setup.py#L16

 S++



   On Thursday, March 12, 2015 2:54 PM, Stuart Axon stua...@yahoo.com
 wrote:



 For closure:  The solution was to make a Command class + implement
 finalize_options to fixup the paths in distribution.data_files.


 Source:

 # https://gist.github.com/stuaxo/c76a042cb7aa6e77285b
 
 Install a file into the root of sitepackages on windows as well as linux.

 Under normal operation on win32 path_to_site_packages
 gets changed to '' which installs inside the .egg instead.
 

 import os

 from distutils import sysconfig
 from distutils.command.install_data import install_data
 from setuptools import setup

 here = os.path.normpath(os.path.abspath(os.path.dirname(__file__)))

 site_packages_path = sysconfig.get_python_lib()
 site_packages_files = ['TEST_FILE.TXT']

 class _install_data(install_data):
 def finalize_options(self):
 
 On win32 the files here are changed to '' which
 ends up inside the .egg, change this back to the
 absolute path.
 
 install_data.finalize_options(self)
 global site_packages_files
 for i, f in enumerate(list(self.distribution.data_files)):
 if not isinstance(f, basestring):
 folder, files = f
 if files == site_packages_files:
 # Replace with absolute path version
 self.distribution.data_files[i] = (site_packages_path,
 files)

 setup(
 cmdclass={'install_data': _install_data},
 name='test_install',
 version='0.0.1',

 description='',
 long_description='',
 url='https://example.com',
 author='Stuart Axon',
 author_email='stua...@yahoo.com',
 license='PD',
 classifiers=[],
 keywords='',
 packages=[],

 install_requires=[],

 data_files=[
 (site_packages_path, site_packages_files),
 ],

 )



 On Tue, 10 Mar, 2015 at 11:29 PM, Stuart Axon stua...@yahoo.com wrote:

 I had more of a dig into this, with a minimal setup.py:
 https://gist.github.com/stuaxo/c76a042cb7aa6e77285b setup calls
 install_data On win32 setup.py calls install_data which copies the file
 into the egg - even though I have given the absolute path to sitepackages
 C:\ python setup.py install  running install_data creating
 build\bdist.win32\egg copying TEST_FILE.TXT - build\bdist.win32\egg\ 
 On Linux the file is copied to the right path: $ python setup.py install
 . installing package data to build/bdist.linux-x86_64/egg running
 install_data copying TEST_FILE.TXT -
 /mnt/data/home/stu/.virtualenvs/tmpv/lib/python2.7/site-packages 
 *something* is normalising my absolute path to site packages into just '' -
 it's possible to see by looking at self.data_files in the 'run' function
 in: distutils/command/install_data.py - on windows it the first part has
 been changed to '' unlike on linux where it's the absolute path I set...
 still not sure where it's happening though. *This all took a while, as
 rebuilt VM and verified on 2.7.8 and 2.7.9.. S++

 On Monday, March 9, 2015 12:17 AM, Stuart Axon stua...@yahoo.com wrote:
  I had a further look - and on windows the file ends up inside the .egg
 file, on linux it ends up inside the site packages as intended. At a guess
 it seems like there might be a bug in the path handling on windows. .. I
 wonder if it's something like this
 http://stackoverflow.com/questions/4579908/cross-platform

Re: [Distutils] Installing a file into sitepackages

[Ionel Cristian Mărieș]

Hey,

If you just want to copy a out-of-package file into site-package you could
just override the build command and copy it there (in the build dir).
Here's an example:
https://github.com/ionelmc/python-hunter/blob/master/setup.py#L27-L31 -  it
seems to work fine with wheels.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Mon, Mar 16, 2015 at 11:02 AM, Stuart Axon stua...@yahoo.com wrote:

 Hi All
 This, and another memory-leak bug were triggered by the sandbox.
 Would it be possible to either add an API to exempt files, or just allow
 writing within site packages, even if just for .pth files ?

 I'm monkey patching around these for now
 https://github.com/stuaxo/vext/blob/master/setup.py#L16

 S++



   On Thursday, March 12, 2015 2:54 PM, Stuart Axon stua...@yahoo.com
 wrote:



 For closure:  The solution was to make a Command class + implement
 finalize_options to fixup the paths in distribution.data_files.


 Source:

 # https://gist.github.com/stuaxo/c76a042cb7aa6e77285b
 
 Install a file into the root of sitepackages on windows as well as linux.

 Under normal operation on win32 path_to_site_packages
 gets changed to '' which installs inside the .egg instead.
 

 import os

 from distutils import sysconfig
 from distutils.command.install_data import install_data
 from setuptools import setup

 here = os.path.normpath(os.path.abspath(os.path.dirname(__file__)))

 site_packages_path = sysconfig.get_python_lib()
 site_packages_files = ['TEST_FILE.TXT']

 class _install_data(install_data):
 def finalize_options(self):
 
 On win32 the files here are changed to '' which
 ends up inside the .egg, change this back to the
 absolute path.
 
 install_data.finalize_options(self)
 global site_packages_files
 for i, f in enumerate(list(self.distribution.data_files)):
 if not isinstance(f, basestring):
 folder, files = f
 if files == site_packages_files:
 # Replace with absolute path version
 self.distribution.data_files[i] = (site_packages_path,
 files)

 setup(
 cmdclass={'install_data': _install_data},
 name='test_install',
 version='0.0.1',

 description='',
 long_description='',
 url='https://example.com',
 author='Stuart Axon',
 author_email='stua...@yahoo.com',
 license='PD',
 classifiers=[],
 keywords='',
 packages=[],

 install_requires=[],

 data_files=[
 (site_packages_path, site_packages_files),
 ],

 )



 On Tue, 10 Mar, 2015 at 11:29 PM, Stuart Axon stua...@yahoo.com wrote:

 I had more of a dig into this, with a minimal setup.py:
 https://gist.github.com/stuaxo/c76a042cb7aa6e77285b setup calls
 install_data On win32 setup.py calls install_data which copies the file
 into the egg - even though I have given the absolute path to sitepackages
 C:\ python setup.py install  running install_data creating
 build\bdist.win32\egg copying TEST_FILE.TXT - build\bdist.win32\egg\ 
 On Linux the file is copied to the right path: $ python setup.py install
 . installing package data to build/bdist.linux-x86_64/egg running
 install_data copying TEST_FILE.TXT -
 /mnt/data/home/stu/.virtualenvs/tmpv/lib/python2.7/site-packages 
 *something* is normalising my absolute path to site packages into just '' -
 it's possible to see by looking at self.data_files in the 'run' function
 in: distutils/command/install_data.py - on windows it the first part has
 been changed to '' unlike on linux where it's the absolute path I set...
 still not sure where it's happening though. *This all took a while, as
 rebuilt VM and verified on 2.7.8 and 2.7.9.. S++

 On Monday, March 9, 2015 12:17 AM, Stuart Axon stua...@yahoo.com wrote:
  I had a further look - and on windows the file ends up inside the .egg
 file, on linux it ends up inside the site packages as intended. At a guess
 it seems like there might be a bug in the path handling on windows. .. I
 wonder if it's something like this
 http://stackoverflow.com/questions/4579908/cross-platform-splitting-of-path-in-python
 which seems an easy way to get an off-by-one error in a path ?




 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] pip upgrade woes

[Ionel Cristian Mărieș]

Hello,

There's one issue with pip upgrade that annoys me occasionally, and when it
does it's very annoying.

Every so often me or some customer has to upgrade some core packages like
pip, setuptools or virtualenv on some machine. Now this becomes very
annoying because said packages were installed there with either
easy_install or just `setup.py install`. Several upgrades like that and now
the machine has a hadful of eggs there. Lots of mistakes were made but
what's done is done.

Now, if `pip upgrade pip setuptools virtualenv` it will run around a bit,
flap its wings and in the end it's not gonna fly like an eagle, and won't
be able to go beyond it's cursed fences. An so, I feel like chicken farmer
when I try to upgrade packages and pip can't upgrade them. Cause those old
eggs are still going to be first on sys.path. And when I try to run pip
it's still that old one.

Sometimes few `pip uninstall` solve the issue, but most of the time I have
to manually remove files because pip can't figure out what files to remove.

One big issue is that pip uninstall only uninstalls the first package it
finds, and similarly, pip install will only uninstall the first package it
finds before coping the new files.

This whole process becomes a whole lot more annoying when you have to
explain someone how to cleanup this mess and get latest pip and setuptools.

So I'm wondering if there's a better way to cleanup machines like that. Any
ideas?

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setup_requires for dev environments

[Ionel Cristian Mărieș]

On Thu, Mar 19, 2015 at 10:38 PM, Nick Coghlan ncogh...@gmail.com wrote:

 I believe setuptools can already do this (as setup-requirements.txt),
 but it's a generated file that people tend not to check into source control.


​Isn't that just some project's convention - they just read it up ​in
setup.py? Setuptools doesn't do anything with it by itself.

Also, if pip were to support a setup-requirements.txt, should setuptools
also support that natively? What about repository url dependencies?

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setup_requires for dev environments

[Ionel Cristian Mărieș]

The --record is for making a list of installed files. You don't need it if
you don't use record.txt anywhere.

As for --single-version-externally-managed, that's unrelated to your
setup_requires pain - you probably already have the eggs around, so they
aren't redownloaded. What --single-version-externally-managed does is force
the package to install in non-egg form (as distutils would). That also
means only setup.py that uses setuptools will have the
--single-version-externally-managed option available.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Thu, Mar 19, 2015 at 6:17 PM, Chris Barker chris.bar...@noaa.gov wrote:

 On Thu, Mar 19, 2015 at 9:12 AM, Ionel Cristian Mărieș cont...@ionelmc.ro
  wrote:

 ​Worth considering​, if you can afford it, to have a local patch that you
 apply before building. Then you have all the necessary fixes (like remove
 the setup_requires) in that patch file.


 yup -- that's a option -- but a really painful one!

 I did, in fact, find an incantation that works:

 $PYTHON setup.py install --single-version-externally-managed
 --record=/tmp/record.txt

 but boy, is that ugly, and hard to remember  why not a --no-deps flag?

 (and I have no idea what the --record thing is, or if it's even
 neccessary...

 -Chris


 This is a popular approach in Debian packages - they can have all kinds of
 fixes for the upstream code.



 Thanks,
 -- Ionel Cristian Mărieș, http://blog.ionelmc.ro




 --

 Christopher Barker, Ph.D.
 Oceanographer

 Emergency Response Division
 NOAA/NOS/ORR(206) 526-6959   voice
 7600 Sand Point Way NE   (206) 526-6329   fax
 Seattle, WA  98115   (206) 526-6317   main reception

 chris.bar...@noaa.gov

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setup_requires for dev environments

[Ionel Cristian Mărieș]

On Thu, Mar 19, 2015 at 5:38 PM, Chris Barker chris.bar...@noaa.gov wrote:

 My use case at the moment is trying to build conda packages from other
 peoples' Python packages - if they use setup_requires, etc, then I'm stuck
 with it.


​Worth considering​, if you can afford it, to have a local patch that you
apply before building. Then you have all the necessary fixes (like remove
the setup_requires) in that patch file.

This is a popular approach in Debian packages - they can have all kinds of
fixes for the upstream code.



Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setup_requires for dev environments

[Ionel Cristian Mărieș]

On Wed, Mar 18, 2015 at 5:33 PM, Chris Barker - NOAA Federal 
chris.bar...@noaa.gov wrote:

 I don't want it downloading and installing dependencies when I go to
 build. That's an install- time task.


Sounds to me like you should not use setup_requires then - if you don't
like what it does.

Also, for the whole distutils-sig, I don't understand all the fuss around
this much maligned feature - there are plenty of options to manage
build-time dependencies and tasks - one certainly doesn't need to shoehorn
https://github.com/ipython/ipython/blob/master/setup.py a full blown
build system into setup.py - there's make, invoke, shell scripts and plenty
of other systems that can do that just fine​.

Using too many tools is bad, but misusing tools is far worse.

Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Getting more momentum for pip

[Ionel Cristian Mărieș]

I've only looked at the first couple pages. The existing labels don't
indicate clearly the first/second/fourth goals.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Thu, Mar 5, 2015 at 8:11 PM, Marcus Smith qwc...@gmail.com wrote:




 Currently there are no labels at all for any issue or PR.



 there are labels  https://github.com/pypa/pip/labels
 I put most of these last year.



___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Getting more momentum for pip

[Ionel Cristian Mărieș]

Triaging the issues would help. If, say, I'd like to help it's very
discouraging to look in a bug tracker and not be able to filter down on
what's interesting or important.

Some ideas for triaging goals:

* clear labels for issues that the maintainers want to be fixed (eg: if you
fix it you'd get quick feedback as a maintainer is interested in that
issue).
* clear labels for issues that need discussions, have design issue etc
(blocked issues IOW).
* clear labels for what's a bug or feature.
* clear labels for features that would be accepted but no maintainer has
time or is interested in (the nice to have issues).

Currently there are no labels at all for any issue or PR.


Thanks,
-- Ionel Cristian Mărieș, http://blog.ionelmc.ro

On Thu, Mar 5, 2015 at 7:16 PM, Marcus Smith qwc...@gmail.com wrote:

 So I guess my suggestions boil down to:


 - Add more humans
 - Add more money to make humans more efficient
 - Add more computer automation



 maybe agree to always maintain  X open issues and  Y open PRs, before
 adding features.
 where x can vary as needed, but for starters, x=250, and y=25 sounds
 reasonable.
 this would:
   - force more work on issue and PR backlog
   - force making the tough decisions on whether something is realistically
 going to be worked on and closing it
   - force closing issues that are not getting the responses needed to
 actually work the problem.
   - would more likely cycle in new folks to become committers.



 ___
 Distutils-SIG maillist  -  Distutils-SIG@python.org
 https://mail.python.org/mailman/listinfo/distutils-sig


___
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig