>> * Is there any practical operational or performance limits on the number of
>> mounted XARs you can have? E.g. what's the impact of deploying say a few
>> thousand XARs on any particular machine (generally, of Linux and macOS - I'm
>> not as concerned about Windows :)
> We have tiers (think
On Jul 16, 2018, at 18:14, Nick Terrell wrote:
>
> I collected the XAR benchmark numbers. I spent some time today
> investigating what
> exactly is causing the difference between native and XAR start times. The
> native
> installation I was benchmarking against used
> `pkg_resources.load_entry_
Cooper Ry Lees wrote on 7/13/18 13:51:
Today Facebook Open Sourced a competitor to PEX and other zip based
distribution methods for Python (and potentially other languages). Basically
it's claim to fame is start up time for large modules being similar to regular
on file system modules due to
Donald Stufft wrote:
I don’t think we can rename a mailing list easily, we can create a new one and
archive the old one but that has a lot of churn and breaks people’s filters,
etc.
Although it should be easier to rename if the list is migrated to
Mailman 3 first. Please contact postmaster@
Donald Stufft wrote:
>
> * Very few people actually are using OpenID or Google logins as it is. In one
> month we had ~15k logins using the web form, ~5k using basic auth, and 62
> using Google and 7 using OpenID. This is a several orders of magnitude
> difference.
> * Regardless of how you log
Nick Coghlan wrote:
> The tox model is the one we decided to natively support in Fedora as
> well - while there's only ever one "full" Python 3 stack in the main
> repos (with all the distro API bindings, etc), there are also
> interpreter-only packages for other still supported and/or still
> popu
Chris Withers wrote:
> For me, I use travis-ci coupled with a few local virtualenvs for canary
> versions. Some people like tox here, I never got on with it.
For me, tox is transformative. While there are a couple of usability
issues that my clone army seems to be remiss in fixing, for the most
p
On Dec 13, 2017, at 19:39, Dustin Ingram wrote:
>
> It seems like a small amount of convenience in exchange for a
> significant increase in complexity to me.
I can’t speak to the complexity, but it’s very definitely an important use
case. Imagine when Python 3.10 is out; do you really want to
I'm about to release a new version of importlib_resources, so I want to
get my flit.ini's require-python clause right. We support Python 2.7,
and 3.4 and beyond. This makes me sad:
requires-python = '>=2.7,!=3.0,!=3.1,!=3.2,!=3.3'
Of course, I'd like to write this like:
requires-python = '(>=2
Wes Turner wrote:
> There are author-email and maintainer-email fields.
>
> You could also or instead use a mailing list address for the author-email
> or maintainer-email fields. Newlines work (just like file\nnames)?
>
> With a mailing list, package maintainers can share responsibility (*) and
I think I implicitly knew this, but as I've just released a package (to
be announced soon) that actually has multiple authors, I found out first
hand that PyPI rejects uploads where the author-email field isn't a
completely valid email address, and that there is no support for
multiple author email
On Jun 25, 2017, at 11:33 AM, Nick Coghlan wrote:
>I'd favour "Participate" over any variant of "Contribute", as without
>context, "Contribute" makes me think of financial support in the
>crowdfunding/tip jar sense.
"Participate" may mean two different things.
* Here's the development home, with
On Jun 24, 2017, at 05:34 PM, Brett Cannon wrote:
>So my question/idea is if it would make sense to have separate, explicit
>development and documentation URLs in the PyPI metadata?
Wholehearted +1
I already use PyPI as the first stop for finding out about a library or Python
project. I have a
On Jan 13, 2017, at 10:08 AM, Lukasz Langa wrote:
>PEP: 541
>Title: Package Index Name Retention
Overall, +1
I agree with Steve that some short term name squatting may be appropriate.
I'm not sure how you would word that in the PEP, but it will probably
effectively work itself out anyway. When
On Jan 10, 2017, at 08:24 AM, Donald Stufft wrote:
>python3 -c "import urllib.request,json;
> print(json.loads(urllib.request.urlopen('https://www.howsmyssl.com/a/check').read())['tls_version'])"
For Python 3.5:
python3 -c "import urllib.request,json;
print(json.loads(urllib.request.urlope
On Dec 01, 2016, at 10:45 AM, Freddy Rietdijk wrote:
>Having a compatible set of packages is not only interesting for developers,
>but also for downstream distributions. All distributions try to find a set
>of packages that are working together and release them. This is a lot of
>work, and I think
On Nov 03, 2016, at 11:08 AM, Glyph Lefkowitz wrote:
>I think phrasing this in terms of "perfect" and "good enough" presents a
>highly misleading framing. Examined in this fashion, of course we may
>reluctantly use the "good enough" option, but don't we want the best option?
What are the criteri
On Nov 03, 2016, at 12:54 AM, Nick Coghlan wrote:
>This is also an area where I'm fine with recommending freemium
>solutions if they're the lowest barrier to entry option for new users,
>and "Use GitHub + Travis CI" qualifies on that front.
I won't rehash the GitHub/GitLab debate, but in some of
On Sep 02, 2016, at 05:05 PM, Donald Stufft wrote:
>Do we think that a ~3% usage of Python 2.6 and being end-of-life'd for ~3
>years is enough to start deprecating and dropping 2.6?
Yes!
Cheers,
-Barry
pgpCalDLuc3vp.pgp
Description: OpenPGP digital signature
___
On Aug 22, 2016, at 02:29 PM, Daniel Holth wrote:
>1. If it's a zip, nested zips like so,
>
>setup.py
>README
>(metadata)
>data.zip
That would be much more disruptive to downstream consumers of sdists.
Cheers,
-Barry
pgpcWwl_cnoP1.pgp
Description: OpenPGP digital signature
On Aug 22, 2016, at 09:14 PM, Nick Coghlan wrote:
>In that case, perhaps the way to go for sdists (at least for now)
>would be to continue allowing both .tar.gz and .zip, but disallow
>uploading both of them for any given release?
I'd prefer allowing uploading of both formats for now, with mild e
On Aug 17, 2016, at 03:21 PM, Nick Coghlan wrote:
>This means that the situation we've managed to get to now is that we
>have wheels as a satisfactory replacement for the "binary
>distribution" use case, but we haven't even *tried* to replace eggs
>for the "standalone path entry" use case.
I'm ve
On Aug 15, 2016, at 05:39 PM, Donald Stufft wrote:
>so narrowing it down to only .tar.gz and .tgz is pretty safe, but practically
>nobody uses .tgz anyways so why bother?
I agree with all of your reasoning. FWIW, I personally use .tgz all the time
when making backups of things locally, but rarel
On Aug 15, 2016, at 03:09 PM, Donald Stufft wrote:
>Out of all of these, I think that we can easily remove bdist_dmg, bdist_rpm,
>and bdist_dumb. I also believe that there is a strong case for removing
>bdist_msi and bdist_wininst. I also think we should consider removing
>bdist_egg.
+1 for all o
On Jul 26, 2016, at 01:24 PM, Nick Coghlan wrote:
>The PSF has considered this, but there's not a lot of value we could
>provide above and beyond other organisations that already do this for
>open source projects in general. For example:
>
>- Software Freedom Conservancy
>- Software in the Public
On May 12, 2016, at 04:34 PM, Donald Stufft wrote:
>So my response to this is, let's pretend for a minute that we have the
>greatest and most amazing setup for verifying that the key 0x6E3CBCE93372DCFA
>belongs to me. What's your next step? How do you verify that I'm allowed to
>release for pip?
On May 12, 2016, at 07:41 AM, Donald Stufft wrote:
>I am aware of a single tool anywhere that actively supports verifying the
>signatures that people upload to PyPI, and that is Debian's uscan
>program. Even in that case the people writing the Debian watch file have to
>hardcode in a signing key i
On May 09, 2016, at 08:30 PM, Donald Stufft wrote:
>How hard is it to bundle it with pip by copying the source files into
>pip._vendor.*
Every time another package is vendored, a kitten falls off a unicorn. ;)
Cheers,
-Barry
pgpetwbrYXBeb.pgp
Description: OpenPGP digital signature
On May 08, 2016, at 09:05 AM, Robert Collins wrote:
>E.g. use setup.cfg now. Add pybuild.toml later. (btw, terrible name,
>as pybuild is a thing in the debian space, and this will confuse the
>heck out of folk). https://wiki.debian.org/Python/Pybuild
Yes, please don't call it pybuild ;)
Also, I
On Apr 27, 2016, at 10:00 PM, Alex Grönholm wrote:
>The sdist should include all the source files, including tests and
>documentation. In binary distributions, however, they are just dead
>weight. Do you want the full documentation and test suites to be installed
>for every single dependency when
On Feb 16, 2016, at 06:01 PM, Matthias Klose wrote:
>I know we had such an issue where pip accidentally modified system installed
>files, maybe Barry still remembers the details ...
I don't, but I hope that should not be a problem these days, with modern pip
on modern Debian/Ubuntu systems. We p
On Feb 11, 2016, at 01:58 PM, Nick Coghlan wrote:
>Hmm, I got the py2dsc reference from https://wiki.debian.org/Python/Packaging
>but the newer https://wiki.debian.org/Python/LibraryStyleGuide doesn't appear
>to mention any particular way of generating the initial packaging skeleton
>from the upst
On Feb 10, 2016, at 10:08 AM, Paul Moore wrote:
>But those people will then find that distributing their sources isn't
>something that flit covers, so they'll make up their own approach (if it were
>me, I'd probably just point people at the project's github account).
>
>Once people get set up with
On Nov 05, 2015, at 04:08 PM, Donald Stufft wrote:
>One benefit of the third option is that we can remove the need to directly
>copy the bundled libraries into the pip source code and we can install just
>bundle it inside the built zip file.
This shouldn't be a problem from Debian's p.o.v. if we
On Oct 29, 2015, at 10:52 PM, Marcus Smith wrote:
>> If python-dev ends up adopting GitLab for the main PEPs repo, then we
>> should be able to move the whole process there, rather than needing to
>> maintain a separate copy.
>>
>will that be as open as pypa/interoperability-peps? if it's closed
On Oct 10, 2015, at 06:48 AM, Stuart Axon via Distutils-SIG wrote:
>Hi, I built a package of using stdeb, any idea if these are acceptable to
>debian + ubuntu, and where to start / who to contact to get a package
>included in those distros ? S++
You can contact debian-pyt...@lists.debian.org
On Oct 07, 2015, at 09:46 AM, Ben Finney wrote:
>So “I'm a big fan of putting tests inside the [Python] package
>[directory]” can't be motivated by “Having the tests there in the
>installed package”. The two aren't related, AFAICT.
It makes it easier for sure. When the tests are inside the packa
On Oct 07, 2015, at 08:35 AM, Marius Gedminas wrote:
>I have hopes for 'tox.ini' becoming the standard way to test a Python
>project.
As do I, modulo outliers of course. I'd like to see 90% of PyPI packages have
a tox.ini.
Cheers,
-Barry
pgpxJ0ovIWbuL.pgp
Description: OpenPGP digital signatur
On Oct 07, 2015, at 08:18 AM, Donald Stufft 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 execu
On Oct 07, 2015, at 08:54 AM, Ben Finney wrote:
>Barry Warsaw writes:
>
>> I'm a big fan of putting the tests inside the package. I've often
>> looked at a package's tests to get a better understanding of something
>> that was unclear for the documentatio
On Oct 06, 2015, at 05:41 PM, Donald Stufft wrote:
>I’m not sure I understand what you’re advocating here, it sounds like you
>want your tests at something like mycoolproject/tests so that they are
>importable from mycoolproject.tests… but then you talk about symmetry with
>docs/ and tests/ which
On Oct 07, 2015, at 08:51 AM, Ben Finney 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.
It's *a* standard but not *the* standard,
On Oct 06, 2015, at 08:18 PM, Ben Finney wrote:
>Yes, this is a sensible approach:
>
>* The source package contains all the source files a developer would use
> to make further changes and test them.
>
>* The package for installation contains only those files useful run-time
> users, plus metada
On Oct 06, 2015, at 10:44 AM, Antoine Pitrou wrote:
>Doesn't / didn't setuptools have something called test_requires?
Since I pretty much use tox everywhere these days, I've taken to defining test
requirements in my tox.ini rather than my setup.py.
Cheers,
-Barry
pgpDfbZCf3GwZ.pgp
Description:
On Oct 06, 2015, at 09:51 AM, Antoine Pitrou wrote:
>The PyP"A" should definitely fix its sample project to reflect good
>practices.
Here's my own sample project. There are actually two git branches, one with
an extension module and one with pure Python.
https://gitlab.com/warsaw/stupid
Cheers
On Oct 06, 2015, at 11:33 AM, David Cournapeau wrote:
>I would like to hear their rationale before guessing. It is hard for me to
>imagine they would not rather test the binaries rather than from sources.
>Something as simple as making sure you have not forgotten runtime
>dependencies becomes much
On Oct 06, 2015, at 06:21 AM, Donald Stufft wrote:
>FreeBSD relies on ``python setup.py test`` as it's preferred test invocation,
>so it apparently doesn't find it useful either.
Oh how I wish there was a standard way to *declare* how to run the test suite,
such that all our automated tools (or t
On Oct 06, 2015, at 05:54 AM, Donald Stufft wrote:
>I dislike putting tests inside the package.
I'm a big fan of putting the tests inside the package. I've often looked at a
package's tests to get a better understanding of something that was unclear
for the documentation, or didn't work the way
On May 15, 2015, at 09:48 AM, Donald Stufft wrote:
>One of the things that this brought to light was that the documentation
>upload ability in PyPI is something that is not often used* however it
>represents something which is one of our slowest routes.
I use it for all my packages, mostly becaus
On Apr 22, 2015, at 02:25 PM, Chris Barker wrote:
>That's it. Done. Now all we need is a way to install these things -- well
>that's easy, each sub-package installs itself just like it would, maybe
>overwriting the top level directory name and the __init__.py, if another
>sub-package has already i
On Apr 23, 2015, at 07:08 AM, Robert Collins wrote:
>PEP-420 and legacy packages being mixed for one namespace doesn't work at all
>today - in principle fixable via changes to both setuptools and importlib -
>but it was about here that the other openstack folk said 'ok wow, lets just
>stop using n
On Apr 01, 2015, at 04:14 PM, Thomas Güttler wrote:
>Is it possible to get the dependencies of a package without full download
>from pypi?
It would be kind of nice if you could get the package's metadata (e.g
egg-info/entry_points.txt) out of its PyPI JSON blob:
https://pypi.python.org/pypi/fluf
On Mar 31, 2015, at 09:14 AM, Nick Coghlan wrote:
>We need to build from source not just to ensure our binaries match the
>published source code, but also because our build systems are designed to
>let us *patch* the packages before we build them. This is what lets us
>backport security updates, b
On Mar 30, 2015, at 11:56 AM, Donald Stufft wrote:
>Honestly, I don’t think that setup.py as a development interface is that
>bad.
Especially when you cargo cult most of a new project's basic infrastructure[*]
from one that's already working. Sweat out the first one, then reuse. ;)
Cheers,
-Bar
On Feb 10, 2015, at 07:06 PM, Martin v. Löwis wrote:
>I think this is your personal usage primarily. A lot of user just avoid
>having to use a password manager, and use the same password on many
>systems. (Of course, many people also *do* use different passwords, and
>some also use passwords manag
On Feb 10, 2015, at 02:27 PM, Brett Cannon wrote:
>Does Launchpad support OpenID Connect? If so then migrating to that would
>solve this.
No, I don't believe so. I've just filed this bug:
https://bugs.launchpad.net/launchpad/+bug/1420348
>Otherwise it may be time to have a serious look at our
On Feb 08, 2015, at 11:37 PM, Richard Jones wrote:
>Google has discontinued support for OpenID, so we're not going to be
>putting any effort into debugging this issue.
I hope you'll continue to support other OpenID providers, e.g. Launchpad.
Cheers,
-Barry
pgpVJAH8ZQaH8.pgp
Description: OpenP
On Jan 19, 2015, at 07:23 PM, Ben Finney wrote:
>My understanding, based on an answer received elsewhere [0], is that
>omitting the file from ‘setup.py’ but adding it to ‘MANIFEST.in’ causes
>it to be included in the sdist but omitted from install targets.
I haven't read the whole thread (no time
On Jan 13, 2015, at 02:39 PM, Robert Collins wrote:
>Welcome to hell :)
Well, purgatory maybe. I patched the lazr packages I cared about. :)
>So I dug down ridiculously deep into this when investigating a very
>similar issue in the openstack space. I have an alternative solution
>to the ones me
On Jan 03, 2015, at 03:09 AM, Nick Coghlan wrote:
>This was the intended solution when PEP 420 was written - we deliberately
>didn't break old-style namespace packages, we just made them redundant for
>code that only needs to run on 3.3+. This is much easier to learn, since it
>means creating pack
On Jan 01, 2015, at 09:14 PM, Donald Stufft wrote:
>Why are you puzzled by the notion that something designed to work with a
>one mechanism for a particular feature probably does not work with a
>newer, different mechanism for a particular feature? My assumption is that
>setuptools is ensuring tha
On Jan 01, 2015, at 03:20 PM, Tres Seaver wrote:
>That sounds right to me. I never really understood the motivation for
>PEP 420, but if the presence of that file disables it, then it should
>ensure the "old" behavior regardless.
The motivation is described in the PEP, but briefly, on (many, mos
I hope the following makes sense; I've been a little under the weather. ;)
Apologies in advance for the long data-dump, but I wanted to provide as
complete information as possible.
I have ported Mailman 3 to Python 3.4[*]. While working on various
development tasks, I noticed something rather str
On Oct 22, 2014, at 05:00 PM, Kelly Goedert wrote:
>I am new to python. I created a simple python cli application that depends
>on jsonpickle and plumbum.
>
>Using this command python setup.py --command-packages=stdeb.command
>bdist_deb I was able to create a .deb package. But when I try to instal
On Sep 30, 2014, at 04:25 PM, Jeremy Stanley wrote:
>Good to know. The Debian Developer packaging the majority of the
>projects I work on must be in that minority.
IIRC, the OpenStack packagers were probably the most prominent proponent of
release-from-tag.
Cheers,
-Barry
signature.asc
Descrip
On Sep 30, 2014, at 05:40 PM, Wichert Akkerman wrote:
>Debian does allow 3.1.4-1-1. I forgot the exact rules, but I seem to remember
>the package version is considered to start after the last dash. Debian will
>also sort 3.1.4a after 3.1.4 unlike Python rules, so version “massaging”
>might be nece
On Sep 30, 2014, at 02:34 PM, Jeremy Stanley wrote:
>I'm becoming less and less convinced it actually *is* a source
>distribution any more. My constant interaction with downstream Linux
>distro packagers shows a growing disinterest in consuming release
>"tarballs" of software, that they would gene
On Sep 30, 2014, at 11:06 AM, M.-A. Lemburg wrote:
>Installers and PyPI would then regard "3.1.4-1" as belonging to
>release "3.1.4", but being a more current build as a distribution
>file carrying "3.1.4" in its file name.
Please don't literally use "3.1.4-1". That will cause all kinds of havoc
On Sep 29, 2014, at 09:40 AM, Ian Cordasco wrote:
>That's essentially what I see as the chief use-case for
>testpypi.python.org. I don't think pypi.python.org needs to support
>this as well. Simple is better than complex after all :)
Can we then make it easy to upload to testpypi via the cli? Ma
On Sep 28, 2014, at 07:31 PM, Donald Stufft wrote:
>I'd like to discuss the idea of moving PyPI to having immutable files. This
>would mean that once you publish a particular file you can never reupload
>that file again with different contents. This would still allow deleting the
>file or reupload
On Sep 20, 2014, at 06:10 PM, Toshio Kuratomi wrote:
>All distros I can think of have some sort of self-governance whereas pypi is
>more akin to a bunch of customers making use of a service. Some of the
>distro policies don't apply very well in this space. Some do, however, so I
>hope other peop
On Sep 04, 2014, at 10:39 AM, Marcus Smith wrote:
>wouldn't that only update it for the *next* release of debian/ubuntu?
Generally yes. There's also backports, but that's more effort.
https://help.ubuntu.com/community/UbuntuBackports
https://wiki.debian.org/Backports
Cheers,
-Barry
signature
On Sep 03, 2014, at 12:24 PM, Reinout van Rees wrote:
>All of them have ubuntu packages, but especially for gdal we sometimes need a
>newer version. A PPA can help here, but I thought "a wheel could be nice,
>too".
In many cases, it mostly takes an interested person to get Ubuntu and Debian
packa
On Jul 25, 2014, at 08:46 AM, Donald Stufft wrote:
>Yea, I’m not sure whether I like it or not. Probably once we get a for real
>build farm for PyPI setup that will be a pretty reasonable sized carrot for
>people to upload sources.
That's really the right long-term approach, IMO. I'd like to som
On Jul 24, 2014, at 01:28 PM, Richard Jones wrote:
>1. reject wheel uploads in the absence of an sdist in the index (the linux
>guys were really happy about that as a proposal ;)
+1 :)
-Barry
signature.asc
Description: PGP signature
___
Distutils-SIG
On May 02, 2014, at 12:01 PM, Marcus Smith wrote:
>PEP440 has the "local version" idea to distinguish locally patched projects
>from upstream versions.
>http://legacy.python.org/dev/peps/pep-0440/#local-version-identifiers
>
>e.g. Django-1.6.4-1 for a locally patched Django-1.6.4 to place on a
>
On Mar 28, 2014, at 03:06 PM, Daniel Holth wrote:
>Who is going to pycon? I will be there.
I'll be there, for the duration (language summit through sprints). It would
be great to hav an OpenSpace or BoF for discussing the intersection of Python
packaging issues and distros.
-Barry
signature.
On Mar 25, 2014, at 03:35 PM, PJ Eby wrote:
>I think the correct fix would be to change the nspkg.pth magic to check for
>PEP 420 support, but unfortunately it seems we may have to use version
>checking: on rereading PEP 420 I see there's no 'sys.namespace_packages' or
>similar object that can be
On Mar 24, 2014, at 05:53 PM, Donald Stufft wrote:
>See also https://github.com/pypa/pip/issues/3
Hah, yeah. I didn't realize --single-version-externally-managed is implied by
--root, and in fact our Debian build scripts often (either explicitly or
implicitly) define --root, as is the case in la
Apologies for cross-posting, but this intersects setuptools and the import
system, and I wanted to be sure it reached the right audience.
A colleague asked me why a seemingly innocent and common use case for
developing local versions of system installed packages wasn't working, and I
was quite per
On Feb 05, 2014, at 01:05 AM, Nick Coghlan wrote:
>That only works if the system site packages is configured to be
>visible inside the virtual environment - it usually isn't these days.
Really? I do this all the time. It prevents downloading gobs of stuff from
PyPI that my system already provid
On Nov 15, 2013, at 10:12 PM, Donald Stufft wrote:
>The bulk of XMLRPC has been implemented in Warehouse. It would be great if
>people who are using the XMLRPC could try it out using the
>https://preview-pypi.python.org/pypi url.
>
>Currently the search API does not work.
Are you planning on putt
On Oct 12, 2013, at 06:15 PM, Donald Stufft wrote:
>Just to be clear, I don't fault folks for using the /packages/ urls. I was
>just trying to get some sort of idea if anyone actually used that url
>structure or not. I also don't plan on breaking anything for people who do.
>
>That being said, do
On Oct 12, 2013, at 08:50 PM, Floris Bruynooghe wrote:
>Sounds like this could be addressed with a lintian warning and a long
>transition time (~2 years) so leaving proper redirects around would be
>advisable.
Sure, but my point was that people will use the most easily discoverable
pattern availa
On Oct 08, 2013, at 10:44 AM, Donald Stufft wrote:
>Hrm, I'm assuming these require a file listing at
>
>/packages/source/D/ too.
>
>Of course these files should probably be using the simple API and
>not the packages url directly :/
Maybe that URL should be given on the PyPI page for the package?
On Jul 27, 2013, at 10:12 AM, Erik Bernoth wrote:
>did you know that Ubuntu 13.10 (or maybe Debian?) declares those
>packages as untrusted and asks you twice, if you really want to
>install them? Is there anything that can be done about that?
Um, what?
Please provide details. What commands are
On Jul 26, 2013, at 08:38 PM, Paul Moore wrote:
>There are cases where it's useful and appropriate
Sure, I don't disagree. Just that I think the general rule should be:
* Use /usr/bin/env in your source tree
* Use /usr/bin/$python when installed
I think those rules cover the majority of cases.
On Jul 26, 2013, at 09:58 PM, Nick Coghlan wrote:
>Not everybody uses generated script wrappers, though - if there is a
>hardcoded "/usr/bin/env python" or "/usr/bin/python" in a shebang
>line, the Python build tools won't touch it. There's also a whole lot
>of software that isn't packaged at all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Jul 25, 2013, at 03:37 PM, Philip Jenvey wrote:
>What's the value of sys.executable in the brave new world of distributions
>that follow PEP 394?
One use case is locating other scripts/executables that might get installed
next to sys.executable
On Jul 17, 2013, at 08:34 PM, Oscar Benjamin wrote:
>I imagined that distro packaging tools would end up using the wheel as
>an intermediate format when building a deb from a source deb.
Do you mean, the distro would download the wheel or that it would build it
during the build step for the arch
On Jul 17, 2013, at 07:56 PM, Paul Moore wrote:
>The long-term intent is to remove executable setup.py. When this happens,
>definitely consumers (end users, Python tools like pip, and distro
>packaging systems) will have some migration work to do. Keeping that
>manageable will definitely be import
On Jul 17, 2013, at 11:46 AM, Daniel Holth wrote:
>I'd like to see an ambitious person begin uploading wheels that have
>no traditional sdist.
You're not getting rid of sdists are you?
Please note that without source distributions (preferably .tar.gz) your
package will never get distributed on a
On Jul 10, 2013, at 09:50 PM, Paul Moore wrote:
>I think "python -m pip" should be the canonical form (used in
>documentation, examples, etc). The unittest module has taken this route, as
>has timeit. Traditionally, python-dev have been lukewarm about the -m
>interface, but its key advantage is th
On Jul 10, 2013, at 02:43 PM, Paul Moore wrote:
>I would find it distinctly irritating if in Python 3.4 I have to type "pip3
>bootstrap" to bootstrap pip - and even worse if *after* the bootstrap the
>command I use is still "pip". (And no, there is currently no "pip3" command
>installed by pip, an
On Jun 05, 2013, at 02:47 PM, Donald Stufft wrote:
>I'm really just trying to get a sense of your workflow to see if I can make
>any changes to improve the process for it.
>
>One of the big problems with download_url is that the data in setup.py is
>used in (and influences the content of) the fina
On Jun 05, 2013, at 12:16 PM, Donald Stufft wrote:
>Where are you updating the version information at? And how are you generating
>a tarball so that it's name has the correct version in it?
It depends on the package, but let's say it's in a version.txt file. Your
implication is correct though -
On Jun 04, 2013, at 04:46 PM, Carl Meyer wrote:
>On 06/04/2013 04:30 PM, Donald Stufft wrote:
>> I'm interested in the use case. How are generating a release without
>> running setup.py sdist?
>
>I think you misunderstood (the way Barry described it wasn't completely
>clear). If I'm reading it co
On Jun 04, 2013, at 03:23 PM, Noah Kantrowitz wrote:
>Do you mean you just don't want to update the version number in setup.py
>before you release?
Correct, although on further reflection, if the alternative download site has
predictable URLs, then it wouldn't be too difficult to calculate the ne
Like many of you, I got Donald's message about the changes to URLs for
Cheeseshop packages. My question is about the three options; I think I want a
middle ground, but I'm interested to see why you will discourage me from that
.
IIUC, option #1 is fine for packages hosted on PyPI. But what if ou
On Mar 28, 2013, at 03:42 PM, Donald Stufft wrote:
>Don't care how it's done. I don't know Mailman enough to know what is
>possible or how easy things are. I thought packaging-sig sounded nice but if
>you can't rename + redirect or merge or something in mailman I'm down for
>whatever.
Renaming ca
1 - 100 of 284 matches
Mail list logo