[Distutils] Re: pip 18.0 has been released!
Gotcha! On Sun, Jul 22, 2018 at 4:12 PM, Paul G wrote: > That's what "calendar based versioning" means. It refers to the year of > release. See https://calver.org > > > On July 22, 2018 11:07:58 PM UTC, Bill Deegan > wrote: >> >> I noticed the version number jumped from 10.0.1 -> 18.0 >> Is there a reason for such? >> Change in version numbering policy which I missed reading? >> >> On Sun, Jul 22, 2018 at 4:07 AM, Paul Moore wrote: >> >>> Yay! Congratulations on the release, and thanks for all the work you >>> put into it. >>> >>> Paul >>> >>> On 22 July 2018 at 11:51, Pradyun Gedam wrote: >>> > On behalf of the PyPA, I am pleased to announce that pip 18.0 has just >>> > been released. >>> > >>> > To install pip 18.0, you can run >>> > >>> > python -m pip install --upgrade pip >>> > >>> > or use get-pip as described in https://pip.pypa.io/en/latest/ >>> installing. >>> > Note that if you are using a version of pip supplied by your >>> > distribution vendor, vendor-supplied upgrades will be available in due >>> > course (or you can use pip 18 in a virtual environment). >>> > >>> > This is the first pip release since adopting 3 month release cadence >>> and >>> > a Calendar based versioning scheme (also known as CalVer). In simpler >>> > words, there will be a new pip release every 3 months unless there are >>> > no changes since the previous release. More details such as release >>> > months can be found in pip's development documentation. >>> > >>> > The highlights of this release are: >>> > >>> > - Python 3.3 is no longer supported - if you need pip on Python 3.3, >>> > you should stay on pip 10, which is the last version to support >>> Python >>> > 3.3. >>> > - Complete PEP 518 support - includes support for installation of build >>> > dependencies from source and Unicode support on Python 2 and Windows >>> > - New --prefer-binary flag, to prefer older wheels over newer sdists >>> > - Many bug fixes and minor improvements >>> > >>> > Thanks to everyone who put so much effort into the new release. Many of >>> > the contributions came from community members, whether in the form of >>> > code, participation in design discussions and/or bug reports. The pip >>> > development team is extremely grateful to everyone in the community for >>> > their contributions. >>> > >>> > Thanks, >>> > Pradyun >>> -- >>> Distutils-SIG mailing list -- distutils-sig@python.org >>> To unsubscribe send an email to distutils-sig-le...@python.org >>> https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ >>> Message archived at https://mail.python.org/mm3/ar >>> chives/list/distutils-sig@python.org/message/5F2LHKKTCSODTXY >>> BDYKIX2OTMYRFSKCE/ >>> >> >> -- Distutils-SIG mailing list -- distutils-sig@python.org To unsubscribe send an email to distutils-sig-le...@python.org https://mail.python.org/mm3/mailman3/lists/distutils-sig.python.org/ Message archived at https://mail.python.org/mm3/archives/list/distutils-sig@python.org/message/OLVLTIVKCOGTC5VAHQJKE6AQL3T3HB2B/
[Distutils] Claim/remove pypi package named sc0ns
Greetings, There's a package named sc0ns which is an ancient packaging of a SCons release: https://pypi.python.org/pypi/sc0ns vs. https://pypi.python.org/pypi/SCons Is it possible to have the sc0ns package removed/hidden? And/or is there a way to contact that package owner to request same? Thanks, Bill Deegan SCons Project Co-Manager ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Finishing up PEP 517
Daniel,
Perhaps the better way to go about it than to call scons N times is to have
N variant dirs? where there's a variant dir for each build type you want,
and then youd call
scons build_wheel
which is aliased Alias('build_wheel','variant_dir for building wheel path')
Maybe bring this up on scons users mailing list and we'll see if it can be
resolved?
On Wed, Jun 28, 2017 at 6:42 PM, Daniel Holth wrote:
> I was able to implement PEP 517 build_wheel and build_sdist for enscons
> (on bitbucket), and a click cli calling any backend mentioned in
> pyproject.toml. Pretty simple. Not sure what to do with the config
> dictionary.
>
> SCons is not designed to be called twice in the same process with
> different arguments. It would be easier for me to know that pip would only
> invoke one PEP 517 function per subprocess, or to know all target
> directories in advance. Otherwise the enscons.api subprocess has to invoke
> SCons in another subprocess. SCons also builds all targets (wheel and sdist
> in same invocation) by default.
>
> "Alakazam!"
>
> On Wed, Jun 28, 2017 at 3:52 PM Thomas Kluyver
> wrote:
>
>> On Wed, Jun 28, 2017, at 06:07 PM, Daniel Holth wrote:
>>
>> Is there a prototype implementation of pep 517 yet?
>>
>>
>> - Flit has a PR with a prototype backend implementation, though it's not
>> up to date with all the changes the PEP has undergone. I'll update it when
>> we've agreed on a spec - it's still a fast moving target right now.
>> - I have a prototype module frontends could use to call hooks here:
>> https://github.com/takluyver/pep517 . It's mostly up to date, except for
>> the issue with using sdist as a fallback for copying files for a wheel.
>>
>> Re: magic strings - like Nathaniel said, I haven't noticed them as part
>> of any proposal so far.
>>
>> Thomas
>> ___
>> 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-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Can't re-upload package?
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
Re: [Distutils] force static linking
Gordon, If you are sure that your dev and production environments match, then you should have same shared libraries on both, and no need for static linkage? -Bill On Mon, Mar 23, 2015 at 11:36 AM, Dan Stromberg drsali...@gmail.com wrote: On Thu, Sep 11, 2014 at 5:28 AM, gordon wgordo...@gmail.com wrote: Hello, I am attempting to build statically linked distributions. I am using docker containers to ensure the deployment environment matches the build environment so there is no compatibility concern. Is there any way to force static linking so that wheels can be installed into a virtual env without requiring specific packages on the host? Maybe pass -static in $LDFLAGS? Just a wild guess really. ___ 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
