ruamel.ordereddict Activity
Brought to you by:
anthon
Activity for ruamel.ordereddict
-
Anthon van der Neut modified ticket #14
Generate windows wheel for latest version 0.4.15
-
I had to update Appveyor as the last build of ordereddcit was from before bitbucket retarded to git only. I have not tested the result, just uploaded it.
-
Jean-Christophe Fillion-Robin posted a comment on ticket #14
Background, this would fix the installation of scikit-ci [1] on appveyor: https://ci.appveyor.com/project/scikit-build/scikit-build/builds/38639050/job/9b4pi596l9kctlkd https://github.com/scikit-build/scikit-build/blob/c0741f9a1de9dd97e0a1e6f0b3b02fcd76221418/appveyor.yml#L61-L64 [1] https://pypi.org/project/scikit-ci/
-
Generate windows wheel for latest version 0.4.15
-
Rajeev Menon posted a comment on ticket #12
Thank you so much!
-
Henrik Poulsen posted a comment on ticket #13
Since posting this I have pinned to a previous version. Thanks for the fast reply and information around what happened.
-
This is not a breaking change, it is just a result of me not having supplied a .whl file. If you cannot compile from source (or have the time to wait until I can provide wheels for python versions that have been EOL for months, so there are some difficulties generating that), please pin the version on the last one that works. The actual change is minor and doesn't affect functionality
-
Installing 0.4.15 on windows fails
-
This is not a breaking change, it is just a result of me not having supplied a .whl file. If you cannot compile from source (or have the time to wait until I can provide wheels for python versions that have been EOL for months, so there are some difficulties generating that), please pin the version on the last one that works.
-
Installing 0.4.15 on windows fails
-
Thanks for reporting. I thought I had this fixed , and I for sure had seen how pyrsistent has fixed the issue, but somehow managed to forget about this during my holidays in September.
-
"moduleInit" symbol collision causing SystemError on import
-
I uploaded 0.4.15 to PyPI, there are no(and possible will not be) wheels for MacOS/Windows
-
fix issue 12
-
Added tag 0.4.15 for changeset d9cf55c5d796
-
Renaming module init method
-
"moduleInit" symbol collision causing SystemError on import
-
ruamel.ordereddict released /ruamel.ordereddict-0.4.14.tar.xz
-
Anthon van der Neut committed [06b0a5]
initial with skips
-
Anthon van der Neut committed [274fd8]
added .travis.yml
-
Anthon van der Neut committed [fb90a9]
add LICENSE to sdist
-
Anthon van der Neut committed [983a52]
Added tag 0.4.13 for changeset cee6b6a0aa94
-
Anthon van der Neut committed [9ffb38]
fix issue #6, compile on Cygwin
-
Anthon van der Neut committed [924e2b]
version: 0.2a
-
Anthon van der Neut committed [264b9e]
version: 0.3
-
Anthon van der Neut committed [a130be]
tests , makefile
-
Anthon van der Neut committed [cee6b6]
fix readme
-
Anthon van der Neut committed [70b533]
Added tag 0.4.14 for changeset fb90a92bc06e
-
Anthon van der Neut committed [4ab4e2]
version: 0.4
-
Anthon van der Neut committed [c1b50d]
version: 0.4.5
-
Anthon van der Neut committed [81375e]
step 3.
-
Anthon van der Neut committed [e683a3]
MSVC doesn't handle non-block initial variable declarations as in C89
-
Anthon van der Neut committed [7b55b1]
wheel settings
-
Anthon van der Neut committed [9cccdf]
version: 0.4.3
-
Anthon van der Neut committed [08ed1f]
iter_traverse added
-
Anthon van der Neut committed [e9e5db]
no tox for now
-
Anthon van der Neut committed [b48e60]
initial test working
-
Anthon van der Neut committed [2cc93a]
Added tag 0.4.12 for changeset 9ffb385dc7fa
-
Anthon van der Neut committed [a0f1a2]
version: 0.4.1
-
Anthon van der Neut committed [e24fe2]
incorporated changes in dictobject.c between 2.5.1-2.5.6 and 2.6.9
-
Gianfranco Costamagna committed [c09490]
Fix typo
-
Anthon van der Neut committed [6886f1]
update revision info
-
Anthon van der Neut committed [0b3022]
version: 0.2
-
Anthon van der Neut committed [7417da]
add dictiter garbage collection from 2.6.9 in New **and** Dealloc
-
Anthon van der Neut committed [8b162f]
update origin
-
Anthon van der Neut committed [6623e2]
version: 0.4.2
-
Anthon van der Neut committed [966f7c]
Added tox
-
Anthon van der Neut committed [505c24]
before addint dictkeys_new et all
-
Anthon van der Neut committed [a3d6ff]
upload to pypi
-
Anthon van der Neut committed [adf92a]
adding tox to appveyor
-
Anthon van der Neut committed [8d9329]
update README, should no longer import _ordereddict
-
Anthon van der Neut committed [efa268]
some helper files
-
Anthon van der Neut committed [e52088]
appveyor
-
Anthon van der Neut committed [088538]
merge changes for py32
-
Anthon van der Neut committed [ef4182]
- py.test used by tox
-
Anthon van der Neut committed [8ae8d9]
prepare for appveyor build
-
Anthon van der Neut committed [75a328]
step 1 of 2.7.9 extracted insert_dict_by_entry
-
Anthon van der Neut committed [7b40e0]
2. step incorporating 2.7.10
-
Anthon van der Neut committed [a65f40]
removed README, added .hgignore
-
Anthon van der Neut committed [2cae9d]
update to use py.test
-
Anthon van der Neut committed [b51f39]
replace README with README.rst
-
Anthon van der Neut committed [44aeb2]
version: 0.4.4
-
collections.OrderedDict is pure Python IIRC, the OrderedDict in 3.x is C based. Not using ruamel.ordereddict makes things slower, but if that is a concern, YAML is not a good choice anyway, so --no-deps should certainly work. It could be that some 3rd party lib relies on some ruamel.ordereddict feature not available in collections.OrderedDict. (after loading a mapping). But that lib would then only work on 2.7 unless the extended the ordereddict class in ruamel.yaml's compat.py like I did for .insert()...
-
Is ruamel.ordereddict strictly necessary on Python 2.7? Or could it be made an optional extra? The code suggests that py27 collections.OrderedDict is enough, because iirc ordereddict.OrderedDict is the same as py27 collections.OrderedDict . If so, then pip install --no-deps ruamel.yaml again is a good enough workaround for Alpine usage if size of disk image is more important than speed. (originally posted on 2019-08-23 at 14:53:19 by John Vandenberg <John Vandenberg@bitbucket>)
-
in the commen setup.py this is solved, but once I found that the dict class had changed as much as it did in 3.3 (or 3.4) and I both realized that my almost working Python 3.1/3.2 version of ruamel.ordereddict needed further rewrite and that someone was redoing the whole thing starting with a tiny subset of what I had implemented I minimalized my effort. That minmal effort included not upgrading to the common setup.py for the latest “release” a month ago. Essentially the setup.py for ruamel.ordereddict...
-
I added verbose for the clib build, and it is also failing, but the build failure is hidden Added ruamel.yaml.clib>=0.1.2; platform_python_implementation == "CPython" and python_version < "3.8" from https://files.pythonhosted.org/packages/6a/6c/7b461053ce5be0d7c8b12dcae9a7c10e8012238a00f6fcd98643ee66d2de/ruamel.yaml.clib-0.1.2.tar.gz#sha256=cee86ecc893a6a8ecaa7c6a9c2d06f75f614176210d78a5f155f8e78d6989509 (from ruamel.yaml>=0.15.5; python_version != "3.4" and python_version < "3.7"->moban) to build...
-
status set to resolved add LICENSE to sdist fixes issue #10 When this change indeed resolves your problem, please Close this issue. (You can do so using the WorkFlow pull-down (close to the top right of this page)) → <<cset fb90a92bc06e="">></cset> (originally posted on 2019-07-27 at 07:57:09)
-
And https://bitbucket.org/ruamel/ordereddict/src/default/test/test_iter2.py doesnt import pytest (originally posted on 2019-07-15 at 08:42:18 by John Vandenberg <John Vandenberg@bitbucket>)
-
Also there is no test/__init__.py , so test discovery doesnt work. (originally posted on 2019-07-15 at 07:02:10 by John Vandenberg <John Vandenberg@bitbucket>)
-
status set to closed (originally posted on 2018-08-16 at 14:06:44 by makkus <makkus@bitbucket>)
-
Brilliant, worked like a charm! Thanks so much, that was the quickest 'ticket-resolve' I've ever experienced :-) (originally posted on 2018-08-16 at 14:06:22 by makkus <makkus@bitbucket>)
-
status set to resolved https://pypi.org/project/ruamel.ordereddict/#files If that solve this issue please Close it (originally posted on 2018-08-16 at 13:35:41)
-
It is actually optional, it will fall back to collections.OrderedDict, but that is much, much slower on Python < 3.5 I'll see what is needed, I might not have to upgrade the version. Now that I have a macOS VM either should not be hard. (originally posted on 2018-08-16 at 13:13:10)
-
Ruamel, are you going to make support for Python 3? One month before py2.7 "die" :) (originally posted on 2019-11-20 at 18:26:02 by Martin D Cernadas <Martin D Cernadas@bitbucket>)
-
I don't know if I am going to invest the 1-2 weeks of work that that wil take , if Ruamel doesn't have a paying customer at least for part of the work involved. (originally posted on 2018-09-03 at 04:57:54)
-
Ruamel, are you going to make support for Python 3? One year and three month before py2.7 "die" :) (originally posted on 2018-09-03 at 00:23:07 by Клюйков Сергей Вячеславович <onegreyonewhite@bitbucket>)
-
sorry, I don't have the correct knowledge to fix the build with Python3, it should be trivial, but my Python knowledge is still too limited :) that '_PyThreadState_Current' probably has just been renamed (originally posted on 2017-08-07 at 08:30:04 by Gianfranco Costamagna <Gianfranco Costamagna@bitbucket>)
-
Did you actually get ordereddict to work on 3.6 with those changes? A year or two ago I started looking at the changes needed for Python 3 (this code is originally from before the Python 3 release) by looking at the dict C source differences going from Python 2.6 -> 3.1 -> 3.2 etc as there was a major break (after 3.3 IIRC). (originally posted on 2017-08-07 at 07:50:45)
-
None (originally posted on 2017-08-07 at 07:37:12 by Gianfranco Costamagna <Gianfranco Costamagna@bitbucket>)
-
(attachment: build.log) (originally posted on 2017-04-30 at 22:25:38 by Reto Gantenbein <ganto82@bitbucket>)
-
I had quite a few changes for 3.2/3.3 from a few years back. I merged those and after that compilation on AppVeyor seemed ok again. I added your #if defined _MSC_VER || defined __CYGWIN__ from line 7 in ordereddict.h, I think the other things are covered, but cannot test. If this solves your cygwin compile problems, then please close this issue. (originally posted on 2017-07-23 at 11:08:25)
-
status set to resolved fix issue #6, compile on Cygwin reported and fix proposed by nowox → <<cset 9ffb385dc7fa="">></cset> (originally posted on 2017-07-23 at 11:05:42)
-
Any news regarding this issue. I am still using my patched version. This is not convenient. (originally posted on 2017-04-09 at 13:17:41 by nowox_ <nowox_@bitbucket>)
-
I am using Windows 10 and with my patch it builds no problems. Would it be possible to pull my patch and put it on pypi ? (originally posted on 2016-10-16 at 15:35:43 by nowox <nowox@bitbucket>)
-
Digging through your patches, it seems you are using gcc 5.4.0 and Python 2.7.10. What version of Windows? I think the gcc is the problem as I still use the gcc 4 series under Linux for development. I'll try to (also) use gcc 5.4 for the next update, but I have to admit the whole cygwin install and setup annoyed me as much in the past as did using Windows for development in the first place (so I might give up). (originally posted on 2016-09-29 at 05:16:22)
-
None (originally posted on 2016-09-17 at 10:21:06 by nowox <nowox@bitbucket>)
-
Howdy! Ansible Container is a Python project that builds/runs a special container to build/run other containers. Inside our special container, yep, we pip install inside of our container because we need it to work - and we control all of the dependencies in that container. But we also use ruamel.yaml outside of the container in the Python app that launches the various containers. A lot of folks, especially those who follow HEAD on GitHub, clone the repo and python setup.py install or python setup.py...
-
If ruamel.yaml is part of an install_requires and not already installed in your container, you are doomed. Your container will need the C compiler installed and and the libyaml from your distribution. I don't know Ansible Container, but if it is like Docker, there is nothing that magically autodetects C library dependencies (like libyaml) in indirectly loaded python packages. Since you are going to have to change your container specification by hand when you are (indirectly) dependent on ruamel.yaml/ruamel.ordereddict,...
-
This would break when ruamel.yaml or ruamel.ordereddict are part of the install_requires of another package in a setup.py file and a user simply runs python setup.py install - that is still a fairly standard thing to do (we're trying to do this with Ansible Container). It would be very helpful/user-friendly if you'd reconsider this issue as valid. (originally posted on 2017-03-24 at 00:16:46 by Joshua Ginsberg <j00bar@bitbucket>)
-
status set to wontfix The setup.py is not up to date, it should just error and tell you to use pip. I'll incorporate that on the next update. (originally posted on 2016-08-21 at 13:27:06)
-
status set to closed No feedback (originally posted on 2016-09-29 at 05:30:15)
-
Does this work without the change? (originally posted on 2016-08-22 at 07:42:26)
-
status set to closed (originally posted on 2016-08-22 at 07:43:20)
-
Yes, sorry, I should have clarified we're aiming for 16.04, not for wily. Thanks for the edification (originally posted on 2015-09-03 at 12:45:34 by Marco Ceppi <Marco Ceppi@bitbucket>)
-
for wily we are on freeze, you can use "requestsync" tool and ask for a ffe to have it. otherwise for wily+1 it will be automatically there (originally posted on 2015-09-03 at 09:08:40 by Gianfranco Costamagna <Gianfranco Costamagna@bitbucket>)
-
Interesting that Gianfranco and I are down a similar path. I just packaged this for Ubuntu, in a PPA at the moment but was going to submit it. We use ruamel.yaml in a project we're looking to have added to the archive and, by proxy, having its dependencies (ruamel.base, ruamel.ordereddict, ruamel.std.argparse) also packaged. Gianfranco, since you've uploaded this to debian I'll but a request to have it sync'd to the Ubuntu archive, however I'm in the same boat, our tool supports py2 and py3 but we're...
-
thanks for the explanation, so I guess a python3 package is useless at this point, Debian is defaulting soon (TM) to python 3.5 and all the effort is not worth a try :) please close this one then! thanks a lot (originally posted on 2015-09-01 at 08:38:08 by Gianfranco Costamagna <Gianfranco Costamagna@bitbucket>)
-
I have done most of the work on a Py3.2 compatible version, but there are some caveats, and the internals of dict between 3.2 (relatively close to 2.7) and 3.3 and then again 3.4/3.5 have changed, as well as the C interfacing. What is mostly holding me back however is that 3.5 will come with its own simple ordereddict in C (built from scratch of course, following the good-old-not-invented-here syndrome that has hindred the standard OrderedDict development as well). I am not sure if someone is going...
-
I updated ruamel.yaml to version 0.6.1, its setup.py now tests for the platform "CPython" before extending the "install_requires" with ruamel.ordereddict. So on pypy dependency on ruamel.yaml should no longer try and pull in ruamel.ordereddict. (originally posted on 2015-03-18 at 18:36:58)
-
Actually this is a C implementation derived from Larosa-Foord's odict module. However you should be able to use the minimalistic OrderedDict from the standard collections module. In compat.py of ruamel.yaml it is tested if ruamel.ordereddict can be loaded (and falls back to OrderedDict if not). You would probably be more helped with me making ruamel.yaml only pull in ruamel.ordereddict if installing on Cpython, currently I only check if I am on a 2.X. Correct? (originally posted on 2015-03-18 at...
1 >
