g in one Dockerfile tended to hit a timeout on Travis. So
> I'm inclined to say that the intermediate image is not any kind of a public
> interface, and you should build it from the git repository if you need it.
>
> Thomas
>
> On Wed, Feb 26, 2020, at 9:12 AM, Sylvain Corl
I am fine with there being a specific base image but I think that it should
be pullable.
On Wed, Feb 26, 2020, 04:06 Wes Turner wrote:
>
>
> On Tue, Feb 25, 2020, 10:03 PM Wes Turner wrote:
>
>>
>> Is there a reason the new manylinux does not just extend centos:6?
>>
>
> https://github.com/pypa
It seems that the base images used for manylinux wheels are not publicly
available.
For example, https://quay.io/pypa/manylinux2010_centos-6-no-vsyscall gives
a 403 error ("you are not authorized to view this resource").
I think that it would make sense for reproducibility purposes to make these
So I actually do use conda (and also maintain dozens of conda-forge
recipes). but I also need to package things on pypi and would like it to be
as consistent as possible with what general purpose package managers do.
___
Distutils-SIG maillist - Distuti
aniel Smith wrote:
> No, I'm trying to ask, like, why you want that. Presumably you have some
> end goal in mind that you think this will help accomplish, and I think it
> would be helpful to know what that is :-).
>
> On May 15, 2017 2:42 PM, "Sylvain Corlay"
>
putting include files into
> virtualenvs?
>
> On May 15, 2017 10:29 AM, "Sylvain Corlay"
> wrote:
>
>> Hi,
>>
>> When distributing python packages that depend on non-python components,
>> the typical way of doing this with general-purpose package mana
The goal in this approach would be to place headers, and binaries in the
same location as if they were installed with a separate package.
On Mon, May 15, 2017 at 7:29 PM, Sylvain Corlay
wrote:
> Hi,
>
> When distributing python packages that depend on non-python components,
> the ty
Hi,
When distributing python packages that depend on non-python components, the
typical way of doing this with general-purpose package managers (linux
distributions, conda) is to place binaries, headers, configuration and
other artefacts for these components in their respective natural locations
u
Hi Nick (re-sending to the list)
On Sun, Sep 4, 2016 at 5:16 PM, Nick Coghlan wrote:
>
> It's important to note that one of our key goals in PyPA is to get to
> a point where the API of a developer's publishing toolchain of choice
> only depends on the *version of the publishing tools* they're u
faster
> setuptools update cycle"
>
> I nominate this as the official policy on API changes for distutils, with
> regular maintenance mode policies applying to anything else.
>
> Top-posted from my Windows Phone
> --
> From: Nick Coghlan
> Se
Hi Brett,
On Sat, Sep 3, 2016 at 8:05 PM, Brett Cannon wrote:
>
>
> If Jason is up for the responsibility that seems like a reasonable
> approach to take. It also helps test out features in setuptools first
> before upstreaming it.
>
>
How do you see `has_flag` get into setuptools? By monkey-patc
Hi Brett,
On Mon, Aug 29, 2016 at 9:52 PM, Brett Cannon wrote:
>
>
>> As we discussed earlier, even though it is not a concern with C, checking
>> for availability of a compiler flag becomes crucial when building
>> extensions with C++ since new flavors of the language emerge every couple
>> of
Distutils seems to be the de-facto standard for building extension modules
for Python and it is used for most of the third-party extensions out there.
I don’t think that it is reasonable to declare that it is now only meant
for Python itself. I actually see a contradiction in pointing out some lack
n't see any reason
> to change it given the ease of getting alternatives.
>
> Cheers,
> Steve
>
> Top-posted from my Windows Phone
> --
> From: Sylvain Corlay
> Sent: 8/28/2016 3:35
> To: Ralf Gommers
> Cc: DistUtils mailing li
Hi All,
The beta deadline for new features is approaching dangerously.
I agree with Thomas that being able to require Python 3.6 for a project
does not appear so distant for me (as soon as it is a Python 3 project
only).
Any chance to get this through? Checking support for language features will
Hi,
Any feedback on this?
Sylvain
On Mon, Aug 22, 2016 at 10:25 AM, Sylvain Corlay
wrote:
> I think that Thomas' proposal makes sense.
>
> I would be ok to also add it to setuptools so that it can be used sooner
> by projects that don
actually be used. I think
> some of the goals of this sig is to be able to completely sunset distutils
> and replace it with much better solutions (plural) that all speak the same
> protocol.
>
>
>
> *From:* Distutils-SIG [mailto:distutils-sig-bounces+tritium-list=
> sdamon
Hi,
On Sun, Aug 21, 2016 at 10:31 PM, Ralf Gommers
wrote:
>
> On top of that there are technical reasons (don't want to test
> combinations of python + setuptools that both change per release) and
> organizational ones (distutils maintenance is terrible, many simple bugfix
> patches don't get m
, 2016 at 5:28 PM, Donald Stufft wrote:
>
> On Aug 21, 2016, at 5:18 AM, Sylvain Corlay
> wrote:
>
> With this reasoning, nothing should ever be added to the standard library.
>
>
>
> Packaging is a bit different than other things because the network effect
> is much m
On Sun, Aug 21, 2016 at 8:40 AM, Nathaniel Smith wrote:
> > Having the `has_flag` in a different location from `has_function` would
> be weird in my opinion.
>
> I think the point though is that in your proposal, has_flag is in
> distutils 3.6, but has_function is in distutils 2.6, 2.7, 3.2, 3.3,
Hi Ralf,
On Sat, Aug 20, 2016 at 11:42 PM, Ralf Gommers
wrote:
>
>> On python-dev and in the bug tracker, Sylvain has understandably asked
>> for a review with an eye to adding this new feature to Python 3.6 whose
>> feature code cutoff is scheduled for a few weeks from now. As release
>> manag
FYI, this could probably be a security issue with wheel: a wheel package
that has an empty list of data files in any important subdirectory of
sys.prefix can delete all the content of that directory upon uninstall or
update.
Thanks,
Sylvain
On Wed, Jun 15, 2016 at 11:30 AM, Sylvain Corlay
I discovered a quite serious bug in wheels (
http://bugs.python.org/issue27317)
When specifying an empty list for the list of data_files in a given
directory, the entire directory is being deleted on uninstall of the wheel,
even if it contained other resources from other pacakges.
Example:
from
.
Thanks,
Sylvain
On Wed, May 25, 2016 at 3:07 PM, Sylvain Corlay
wrote:
> On Wed, May 25, 2016 at 8:35 PM, Tim Smith wrote:
>
>>
>> As a Homebrew maintainer this sounds like something that Homebrew
>> could influence. Are there any packages in the wild that use this
>
On Wed, May 25, 2016 at 8:35 PM, Tim Smith wrote:
>
> As a Homebrew maintainer this sounds like something that Homebrew
> could influence. Are there any packages in the wild that use this
> mechanism? It seems that headers are mostly installed beneath
> site-packages. I don't have strong feelings
Hello everyone,
This is my first post here so, apologies if I am breaking any rules.
Lately, I have been filing a few bug reports and patches to distutils on
bugs.python.org that all concern the installation and build of C++
extensions.
*1) The distutils.ccompiler has_flag method.*
(http://bugs.
For the build, one could use continuous integration providers like
appveyor, circleci and travisci to perform the builds. This is what has
been done by conda folks with conda-forge.
On Wed, May 25, 2016 at 11:51 AM, Chris Barker
wrote:
> On Wed, May 25, 2016 at 8:27 AM, Thomas Güttler <
> guet
27 matches
Mail list logo
