On 8 May 2018 at 15:00, Diane Trout wrote:
> On Tue, 2018-05-08 at 16:44 +, Brett Cannon wrote:
>
>
>
> On Mon, 7 May 2018 at 16:54 Diane Trout wrote:
>
> Hi,
>
> I was building a package where I had a README.org file, which
> setuptools couldn't find.
>
> It listed .md as a valid format, so
Hi,
On 31 October 2017 at 05:22, Nick Coghlan wrote:
> On 31 October 2017 at 05:16, RonnyPfannschmidt <
> opensou...@ronnypfannschmidt.de> wrote:
>
>> Hi everyone,
>>
>> since a while now various details of installing python packages in
>> virtualenvs caused me grief
>>
>> a) typically each tox
By the way, some pages on pypi itself are pointing to http:
See, e.g. the "Download URL:" link here:
https://pypi.python.org/pypi/google-appengine
On 27 October 2017 at 17:22, Nathaniel Smith wrote:
> On Oct 27, 2017 11:49, "Alex Domoradov" wrote:
>
> RUN pip install --upgrade pip
>
> Try upg
On 25 August 2017 at 18:02, xoviat wrote:
> While we're waiting for others to respond, what are we going to do with
> respect to the sys.path issue? I don't think there has been discussion on
> that yet.
>
There was plenty of discussion. The summary is:
- removing srcdir from sys.path requires
On 24 August 2017 at 15:13, Thomas Kluyver wrote:
> On Thu, Aug 24, 2017, at 06:20 PM, Daniel Holth wrote:
>
> On Thu, Aug 24, 2017 at 12:34 PM Thomas Kluyver
> wrote:
>
> Is there a reason to ask for an 'unclean' build, though? There may be a
> performance optimisation from reusing cached data,
On 24 August 2017 at 10:41, xoviat wrote:
> On Aug 24, 2017 8:28 AM, "Thomas Kluyver" wrote:
>
>> On Thu, Aug 24, 2017, at 02:21 PM, xoviat wrote:
>>
>> I mean is this golang or Python? In Python, you raise notimplementederror.
>>
>>
>> But there's a NotImplemented singleton in Python as well. T
On 24 August 2017 at 10:28, Thomas Kluyver wrote:
> On Thu, Aug 24, 2017, at 02:21 PM, xoviat wrote:
>
> I mean is this golang or Python? In Python, you raise notimplementederror.
>
>
> But there's a NotImplemented singleton in Python as well. The argument for
> using a return value is that the h
On 23 August 2017 at 01:37, Nick Coghlan wrote:
> [...]
>
> Bootstrapping self-hosted packaging tools is a genuinely hard problem
>
True, but on the other hand, it's the self-hosted packaging tools' own
problem. It's up to the tools themselves to solve it.
if PEP 517 simply establishes that the
Hi,
On Mon, Aug 21, 2017 at 5:39 PM, xoviat wrote:
> This statement comes from something that Donald said:
>>
>> > The unvendoring means that setuptools and the project code are now
>> competing over who gets to define what an acceptable version is for these
>> libraries to be installed with.
>>
Hi Thomas,
On 28 July 2017 at 16:53, Thomas Kluyver wrote:
>
> [...] I have a nagging concern about something that someone mentioned ages
> ago: does it make sense for building sdists and building wheels to be part
> of the same backend?
>
> [...]
>
> So I'd like us to circle back round and reco
Hi Jeremy,
On 20 July 2017 at 10:22, Jeremy Stanley wrote:
> On 2017-07-20 14:55:53 +0200 (+0200), Krzysiek Płachno wrote:
> [...]
> >
> > Or is it possible to this data in any other way (apart from
> > downloading package)?
>
> Unfortunately, no, not with the current state of the Python package
Hi,
On 29 May 2017 at 04:05, Nathaniel Smith wrote:
> On Sun, May 28, 2017 at 10:37 PM, Donald Stufft wrote:
> >
> > [...]
> >
> > 1. Using the {package-name}-{package-version}.dist-info in the
> > get_wheel_metadata() metadata is a mistake I think. In pip currently we
> have
> > a bug we have
Hi Thomas,
Besides figuring out where the repo url is, you have a second problem to
solve:
The command `pip install -e some/path` already has something
unpacked/checked-out in `some/path` to install in development mode.
In which folder would the command `pip install -e some.project`
unpack/check
On 17 March 2017 at 11:47, Paul Moore wrote:
> On 17 March 2017 at 14:40, Nick Coghlan wrote:
> > [...] whichever
> > version of "foo" is first on sys.path will "win", and you won't be able
> to
> > import from the other one (so you'll be able to import "foo.bar" or
> > "foo.baz", but not both).
On 17 March 2017 at 07:32, Paul Moore wrote:
> On 17 March 2017 at 09:58, Ronny Pfannschmidt <
> opensou...@ronnypfannschmidt.de> wrote:
> > [...]
> > in order to address that i'd like to propose to switch
> >
> > from "{distribution}-{version}.dist-info/" to
> "{distribution}.dist-info/"
> >
> >
Hi Tim,
The reason setuptools can't process your package is because setuptools
itself doesn't yet know how to install wheels[1] which pip knows how to
install, and PyQT5 is only available as wheels on PyPI (the files with
`.whl` extension in the `simple` URL you linked).
[1] https://github.com/p
On 13 September 2016 at 19:00, Paul Moore wrote:
> [...]
>
> I'm not honestly sure how big the "installing while a process is
> running" issue would be - I did a few simple experiments and couldn't
> immediately trigger weirdness, but I believe it can happen. And things
> get significantly worse
Hi Sandro,
I don't know what your previous setup did, but in your current setup, your
`buildout.cfg` is not configured to take your `setup.py` into account in
any way.
In the `eggs` setting, only `django`, `ipython` and `django-settings` are
mentioned. To take your `setup.py` into account it shou
On 24 August 2016 at 12:56, Daniel Holth wrote:
> On Wed, Aug 24, 2016 at 10:41 AM Alex Grönholm
> wrote:
>
>> [...]
>>
>
> 19.08.2016, 20:25, Daniel Holth kirjoitti:
>
> Eggs are the only way to add a zipped distribution to PYTHONPATH and have
> setuptools find the metadata (the Python code can
On 19 August 2016 at 14:14, Paul Moore wrote:
> [...]
>
> So, the plan becomes:
>
> 1. Change Python 3.6 to default to .tar.gz on Windows
> 2. Change setuptoos to default to .tar.gz, to catch users of older versions
> 3. Document how to create a source distribution as "python setup.py
> sdist (ad
Spinning this off into its own thread...
On 16 August 2016 at 13:10, Donald Stufft wrote:
>
> On Aug 16, 2016, at 11:15 AM, Leonardo Rochael Almeida <
> leoroch...@gmail.com> wrote:
>
> Specifically, buildout right now has setuptools as its only dependence,
> and bu
Thanks Daniel,
A few corrections and considerations below:
On 16 August 2016 at 09:50, Daniel Holth wrote:
> Wheel should be updated to support the egg use case before egg is removed.
> IIUC this would mostly mean officially supporting 'unzipped wheel' as a
> thing you can add to PYTHONPATH, po
We've been discussing here at least two different problems related to
package maintainership:
1. Abandoned/no-longer-maintained, but previously useful packages
2. namespace and package idea space pollution due to tests/aborted
attempts/packaginginexperience.
I don't have a good idea about 1, and
In all this talk about using a YAML subset, I'm surprised no one mentioned
YAMLish:
https://pypi.python.org/pypi/yamlish
It is a well defined subset of YAML and there are implementations in other
programming languages.
The problem with the 200+-lines-single-file library above is that it
depends
On 6 May 2016 at 13:15, Chris Barker wrote:
> On Fri, May 6, 2016 at 5:41 AM, Nick Coghlan wrote:
>
>> [...]
>
>
>
>> So rather than saying "the bootstrapping dependency declaration file
>> is Python-but-not-really", it's easier to say "it's an ini-file format
>> that can be parsed with the conf
On 3 May 2016 at 15:07, Alex Grönholm wrote:
> Having setuptools process the setup requirements before parsing install
> requirements would be a good step forward. Had that been done before, we
> could've just added a setup requirement for a newer setuptools to enable
> PEP 508 conditional requir
Actually, another thing you can do with the wheels at this point is to take
them for a spin :-)
Have pip in another virtualenv install it by using --find-links, or even
setting your own local index.
If you have tests embedded in your wheel, now would be a good time to run
them.
Best regards,
Le
Re-sending to the list as well:
-- Forwarded message --
From: Leonardo Rochael Almeida
Date: 3 February 2016 at 16:23
Subject: Re: [Distutils] setup('postinstall'='my.py')
To: Alt Sheets
Hi,
[...]
On 3 February 2016 at 14:45, Alt Sheets wrote:
>
Hi,
The thing about setup.py is that it only runs at "build time".
However, it looks like you want to generate a unique id at every install.
Since you mentioned a windows installer, consider adding some code to the
installer itself so that it calls an entry point in your library to
generate this
Hi Nathaniel and Robert,
This is a really nice proposal.
I would only like to see added to this proposal (or another one) that new
versions of installers should offer an option to opt in or out of binary
packages from specific sources.
Right now pip has the switches:
- --no-binary
- --on
Hi Mr(s) Versions,
Your "locate" output shows that you have a manual installation of Python
3.4 on /usr/local, and it's possible that "/usr/local/bin" is ahead of
"/usr/bin" in your PATH, which is why pip3 installs into Python 3.4.
>From your error message with Python 3.5, it seems like your Pyth
On 17 November 2015 at 13:20, Daniel Holth wrote:
> LGTM
>
> Q: Why is build_command a list?
> Q: Why isn't the file name venezuelanbeavercheese.json instead of
> pypa.json?
>
Or why not just use a specific key in setup.cfg instead of a pypa.json
file? ISTM that this PEP expects to find in pypa.
Hi Thomas,
I think your idea could be very useful as an accelerator if installation in
closed environments, as you suggested in your last e-mail, but which wasn't
clear in your first.
After all, in closed environments you have control of the machine
architecture of all clients, and can be reasona
Hi Thomas
On 5 November 2015 at 17:42, Thomas Güttler
wrote:
> Am 05.11.2015 um 14:12 schrieb Leonardo Rochael Almeida:
> > There are other formats also. This distutils doc explain the "native"
> ones:
> >
> > https://docs.python.org/2/distutils/builtdist.ht
There are other formats also. This distutils doc explain the "native" ones:
https://docs.python.org/2/distutils/builtdist.html
On 4 November 2015 at 21:09, Alexander Walters
wrote:
>
>
> On 11/4/2015 15:13, Thomas Güttler wrote:
>
>> From
>> http://python-packaging-user-guide.readthedocs.org/e
This is a nice idea.
It makes it easy to fix problematic `setup.py` files like this [1]:
```
from distutils.core import setup, Extension
import numpy
setup(ext_modules=[Extension("_cos_doubles",
sources=["cos_doubles.c", "cos_doubles.i"],
include_dirs=[numpy.get_include()])])
```
[1
mple
Regards,
Leo
On 8 September 2015 at 16:22, Donald Stufft wrote:
> On September 8, 2015 at 3:21:26 PM, Leonardo Rochael Almeida (
> leoroch...@gmail.com) wrote:
> >
> > Still, I wouldn't want a random binary wheel suddenly finding its way
> into
> > my servers, a
Hi,
Going back in time to this old post, but I think it becomes more relevant
now that Nate's work is being completed:
On 13 August 2015 at 22:47, Nathaniel Smith wrote:
> On Thu, Aug 13, 2015 at 12:30 PM, Leonardo Rochael Almeida
> wrote:
> >
> > On 13 August 201
On 13 August 2015 at 11:07, Nate Coraor wrote:
> On Wed, Aug 12, 2015 at 9:05 PM, Nathaniel Smith wrote:
>
>> On Aug 12, 2015 13:57, "Nate Coraor" wrote:
>> >
>> > Hello all,
>> >
>> > I've implemented the wheel side of Nick's suggestion from very early in
>> this thread to support a vendor-pro
Hi Tres,
On 21 July 2015 at 00:25, Tres Seaver wrote:
> [...]
>
> Even given the "over-specified" platform tags Nick suggests, linux wheels
> won't fully work, because the build-time depes won't be satisfiable *by
> pip*: the burden will be on each project to attempt a build and then
> spit out
Hi,
On 17 July 2015 at 05:22, Nick Coghlan wrote:
> On 17 July 2015 at 03:41, Nate Coraor wrote:
> > [...]
> >
> > As mentioned in the wheels PR, there are some questions and decisions
> made
> > that I need guidance on:
> >
> > - On Linux, the distro name/version (as determined by
> > platform
On 19 May 2015 at 13:28, Chris Barker wrote:
> [...]
> So is it possible for PyPA to grow the features to mange all the python
> bits, and then have things like conda use pip inside of Anaconda, maybe? or
> SOME transition where you can add conda if and only if you need its unique
> features, and
On 18 March 2015 at 14:37, Daniel Holth wrote:
> [...]
>
> The behavior we're aiming for would be:
>
> "installer run setup.py" - installs things
> "python setup.py" - does not install things
Besides that, I'd add that we're also looking for: "python setup.py" (by
itself) should not raise Impor
I have faced an issue with setuptools (and even plain distutils) in the
past that has some resemblance to this.
There was a PyPI package that contained C extensions and headers, and
another python package that had more C extensions, but depended on the
location of the headers on the first package
On 2 December 2014 at 10:53, Reinout van Rees wrote:
> [...]
>
>
> Something I don't understand here is that there *is* a single version
> list. And so it feels like it doesn't really matter that much if you just
> lump all the packages together (like pip does).
>
FWIW, In the past I did mention
I thought distlib was supposed to be that API... Even though pip doesn't
use it.
Though that would mean a new major version of buildout that worked on
wheels exclusively instead of eggs.
Pip itself has an internal API in the `pip.commands` package. From a casual
glance it seems usable from other
I wish there was a way to automatically redirect people requesting PIL to
get Pillow instead. It's a PYPI/setuptools friendly repackaging of PIL that
has been going on for years now:
https://pypi.python.org/pypi/Pillow/2.4.0
On 19 May 2014 23:29, Donald Stufft wrote:
> Just an update, asyncmon
+1
This is potentially useful for Heroku or Google Apps, or anything that
requires all your files to exist inside the build area after build
time from where it creates the blob that is actually pushed to all the
slaves.
On Mon, May 13, 2013 at 4:26 PM, Daniel Holth wrote:
> Sounds like a nice fe
Even on 64 bit windows?
On Wed, Jan 30, 2013 at 2:37 PM, Daniel Holth wrote:
> One more thing: sys.platform != 'win32' is how you write "not windows"
>
>
> On Wed, Jan 30, 2013 at 10:13 AM, Daniel Holth wrote:
>>
>> On Wed, Jan 30, 2013 at 9:58 AM, Jim Fulton wrote:
>>>
>>> On Wed, Jan 30, 2013
How easy it is to know which sections are actually used during a run?
Also, it would be nice to have this info on the output of "buildout annotate"
On Wed, Jan 30, 2013 at 12:18 PM, Philippe Ombredanne
wrote:
> On Wed, Jan 30, 2013 at 1:39 PM, Jim Fulton wrote:
>> On Tue, Jan 29, 2013 at 6:25 P
Sounds nice,
Looks like it could make building distributions based on c-libraries
more predictable (think lxml or pymsql), specially when you explicitly
want to avoid libraries provided by the system.
Of course, it would only be helpful for me if buildout grew support
for tweaking it somehow.
Ch
Hi,
On Tue, Jan 15, 2013 at 10:21 AM, Eric V. Smith wrote:
>
>> [...]
>>
>> I guess I don't understand: "I don't know how hard it'd be top
>> implement but in an ideal world I'd prefer to see develop eggs trump
>> any other sources but still have version requirements checked."
>
> I think it mean
On Mon, Jan 7, 2013 at 12:57 PM, Marius Gedminas wrote:
> [...]
>
> Also, having two similar but slightly distinct mechanisms for version
> pinning? I'm -1 on that.
Yeah, that too (so, overall, a -2 from me :-)
It's one more place to check for/maintain version pin information.
The output of "b
Hi
I see one major issue with this proposal:
Currently, the fact that the versions are in a standard buildout
section, and subject to standard "extends" layering rules for
buildout, means we have two great features:
1. You could locally override the versions file by just providing a
few extra ve
Hi Yoshio,
You didn't provide any details on what is your platform, or how you
installed Python or easy_install.
And most importantly, you didn't explain what "can not install
easy_install for 2.6" means, in terms of error messages you got.
In any case, there's likely a "easy_install-2.6" comman
Hi Alessandro,
If you are going to use the Python that comes with your distribution
(usually referred to as 'System Python'), and that you want to use the
"uno" library that comes with this System Python, that is, you can do
something like:
$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56
Hi,
It seems I cannot override, for a single buildout part, the version
information of the global [versions] section.
Is this possible and I just overlooked something?
If not, I intend to add support for that on zc.recipe.egg and/or
z3c.recipe.scripts recipes.
Any comments?
And where can I fin
Hi Fernando,
Sorry for not being able to get to this earlier, but I didn't want to
leave your message unanswered.
It looks, from your message, that you haven't yet understood how to
specify packages and versions in a buildout configuration. It also
seems like you're trying to dismember python pac
Maybe not a debian-specific workaround, but a setting like:
[buildout]
additional-site-packages =
/usr/lib/python2.6/dist-packages
/usr/local/lib/python2.6/dist-packages
On Wed, Mar 23, 2011 at 14:42, Reinout van Rees wrote:
> On 22-03-11 18:57, Carl Meyer wrote:
>>>
>>> Only: bu
Hi Carl,
On Sun, Mar 20, 2011 at 04:06, Carl Meyer wrote:
> Hi Leonardo,
>
> On 03/19/2011 08:18 PM, Leonardo Rochael Almeida wrote:
>> Another variant of this case, one we're actually facing here at our
>> company (Nexedi) right now, is when you need to compile
Another variant of this case, one we're actually facing here at our
company (Nexedi) right now, is when you need to compile extension
modules with libraries that are newer than the ones in the system, and
you don't have root access. The absense of LD_LIBRARY_PATH means a
segfault on an arbitrary mo
Hi Thomas,
I like your idea in general. I'd like to point to the following
suggestion with patch+test (though it might need some cleanup) that is
not exactly related to what you're proposing, but has to do with the
same thing (relationship between files and checksums):
https://bugs.launchpad.net/
Hi,
With this simple buildout:
[buildout]
parts = m2c
[m2c]
recipe = zc.recipe.egg
eggs =
M2Crypto
I'm getting this failure:
Installing 'M2Crypto'.
We have no distributions for M2Crypto that satisfies 'M2Crypto'.
Getting distribution for 'M2Crypto'.
Running easy_install:
/usr/bin/python "-
Hi all
The zc.recipe.egg:custom recipe allows the specification of build
options for a custom egg. But what do we do if we want to specify
custom build options for an egg that is a dependency of a recipe (or
perhaps the recipe itself)?
Case in point
We have a recipe, erp5.recipe.mysqldatabase, t
64 matches
Mail list logo