On Thu, Nov 3, 2016 at 2:48 PM, Chris Barker wrote:
> On Thu, Nov 3, 2016 at 3:50 AM, Paul Moore wrote:
>> Or there's the
>> option that's been mentioned before, but never (to my knowledge)
>> developed into a complete proposal, for packaging up
On Thu, Nov 3, 2016 at 3:02 PM, Paul Moore wrote:
> It would buy *me* flexibility to use python.org build of Python, or my
> own builds. And not to have to wait for conda to release a build of a
> new version.
you are perfectly free to make your own conda package of python
On Wed, Nov 2, 2016 at 5:02 PM, Matthew Brett
wrote:
> Anaconda has an overwhelming advantage on Windows, in that Continuum
> can bear the licensing liabilities enforced by the Intel Fortran
> compiler, and we can not.
Technically, that's an advantage that a commercial
On 3 November 2016 at 21:48, Chris Barker wrote:
> On Thu, Nov 3, 2016 at 3:50 AM, Paul Moore wrote:
>
>>
>> Even on the "hard" cases like Windows, it may be possible to define a
>> standard approach that goes something along the lines of defining a
>>
On Thu, Nov 3, 2016 at 10:56 AM, Matthew Brett
wrote:
> But - it would be a huge help if the PSF could help with funding to
> get mingw-w64 working. This is the crucial blocker for progress on
> binary wheels on Windows.
for what it's worth, this is a blocker for
On Thu, Nov 3, 2016 at 3:50 AM, Paul Moore wrote:
> Even on the "hard" cases like Windows, it may be possible to define a
> standard approach that goes something along the lines of defining a
> standard location that (somehow) gets added to the load path, and
> interested
On Thu, Nov 3, 2016 at 3:39 AM, Nick Coghlan wrote:
> I don't think there's much chance of any of this ever working on
> Windows - conda will rule there, and rightly so. Mac OS X seems likely
> to go the same way, although there's an outside chance brew may pick
> up some of
On Thu, Nov 3, 2016 at 2:34 AM, Paul Moore wrote:
> On 2 November 2016 at 23:08, Chris Barker wrote:
> > After all, you can use pip from within a conda environment just fine :-)
>
> In my experience (some time ago) doing so ended up with the "tangled
I don't know if it has been mentioned before, but Travis already
provides a way to automatically package and upload sdists and wheels to
PyPI: https://docs.travis-ci.com/user/deployment/pypi/
I've been using it myself in many projects and it has worked quite well.
Granted, I haven't had to
I think we're drifting pretty far off topic here... IIRC the original
discussion was about whether the travis-ci infrastructure could be suborned
to provide an sdist->wheel autobuilding service for pypi. (Answer: maybe,
though it would be pretty awkward, and no one seems to be jumping up to
make
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
> On Nov 3, 2016, at 10:17 AM, Barry Warsaw wrote:
>
> 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
Hi,
On Thu, Nov 3, 2016 at 2:29 AM, Paul Moore wrote:
> On 3 November 2016 at 00:02, Matthew Brett wrote:
>> Anaconda has an overwhelming advantage on Windows, in that Continuum
>> can bear the licensing liabilities enforced by the Intel Fortran
>>
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 3 November 2016 at 10:39, Nick Coghlan wrote:
> It may also be feasible to define an ABI for "linuxconda" that's
> broader than the manylinux1 ABI, so folks can publish conda wheels
> direct to PyPI, and then pip could define a way for distros to
> indicate their ABI is
On 3 November 2016 at 19:10, Nathaniel Smith wrote:
> On Nov 3, 2016 1:40 AM, "Nick Coghlan" wrote:
>> The approach Tennessee and Robert Collins came up with (which still
>> sounds sensible to me) is that instead of dependencies on particular
>> external
On 2 November 2016 at 23:08, Chris Barker wrote:
> After all, you can use pip from within a conda environment just fine :-)
In my experience (some time ago) doing so ended up with the "tangled
mess of multiple systems" you mentioned. Conda can't uninstall
something I
On 3 November 2016 at 00:02, Matthew Brett wrote:
> Anaconda has an overwhelming advantage on Windows, in that Continuum
> can bear the licensing liabilities enforced by the Intel Fortran
> compiler, and we can not. We therefore have no license-compatible
> Fortran
On Nov 3, 2016 1:40 AM, "Nick Coghlan" wrote:
>
> On 3 November 2016 at 05:28, Nathaniel Smith wrote:
> > On Nov 2, 2016 9:52 AM, "Nick Coghlan" wrote:
> >> Tennessee Leeuwenberg started a draft PEP for that first part last
> >> year:
On 3 November 2016 at 05:28, Nathaniel Smith wrote:
> On Nov 2, 2016 9:52 AM, "Nick Coghlan" wrote:
>> Tennessee Leeuwenberg started a draft PEP for that first part last
>> year: https://github.com/pypa/interoperability-peps/pull/30/files
>>
>> dnf/yum, apt,
On 3 November 2016 at 04:39, Chris Barker wrote:
> On Wed, Nov 2, 2016 at 9:49 AM, Nick Coghlan wrote:
>> - you need a system for specifying environmental *constraints* (like
>> dynamically linked C libraries and command line applications you
>> invoke)
21 matches
Mail list logo