Activity for ruamel.yaml.convert
-
Anthon van der Neut committed [b66bde]
Added tag 0.3.0 for changeset 34cc0491bf64
-
Anthon van der Neut committed [104631]
adapt to changes in pip/setuptools that prevented correct install
-
Anthon van der Neut committed [cce442]
Better usability yaml_json/json_yaml, combine/split
-
Anthon van der Neut committed [9400b6]
update of setup.py
-
Anthon van der Neut committed [a4bdfc]
Added tag 0.3.1 for changeset 9400b6b23cda
-
Anthon van der Neut committed [b3fc23]
Added tag 0.3.2 for changeset 3038d6aac5d0
-
Anthon van der Neut committed [cc6c80]
added json sync routines
-
Anthon van der Neut committed [34cc04]
update of setup.py, dependencies
-
Anthon van der Neut committed [078586]
utf-8 decode only for Py3
-
Anthon van der Neut committed [9ecbe1]
Added tag 0.2.2 for changeset 1046316dadfb
-
Anthon van der Neut committed [c28a4a]
first release
-
Anthon van der Neut committed [53e97b]
version
-
Anthon van der Neut committed [3038d6]
update setup.py
-
Anthon van der Neut committed [56763f]
update of setup.py, dependencies
-
Anthon van der Neut committed [a47d62]
update setup.py
-
Anthon van der Neut posted a comment on ticket #2
status set to closed I generated the tar.xz for ruamel.yaml.convert and ruamel.yaml.jinja2. The tar.xz generations is now also part of the add-tag to local repo step, before pushing to bitbucket of the repo and certainly before uploading to pypi. So if things change on PyPI, there should be a new .tar.xz (originally posted on 2019-07-28 at 16:47:25)
-
Those new tarballs worked wonderfully. Thanks so much. I'll let you know when the openSUSE packages have been updated in the main repos. Note .convert tarball with tests hasnt been created yet, but not so important as .cmd has tests which mostly covers .convert. Feel free to close this if you dont intend to provide separate tarballs for .convert. (originally posted on 2019-07-28 at 15:43:37 by John Vandenberg <John Vandenberg@bitbucket>)
-
There is no automation between pypi release and opensuse package being updated. I have a script which searches for new pypi releases, but I run that manually, and only when I have time or reason to do some openSUSE packaging. I'm taking a look at the new releases now. (originally posted on 2019-07-28 at 11:14:51 by John Vandenberg <John Vandenberg@bitbucket>)
-
I split of the .so generation from `ruamel.yaml` into `ruamel.yaml.clib`, which makes a .whl which has no .pth or .py files. At some point I have to look at how to install from the .tar.gz and not get those files. ruamel.yaml is dependent on ruamel.yaml.clib for CPython and 2.7/3.5/3.6/3.7. Currently 3.8 cannot be made yet by manylinux and because installing ruamel.yaml.clib from the tar.gz gets you the .pth (and __init__.py) file, that doesn’t work (unless you remove the .pth by hand). I have a...
-
On CentOS 7.0 the same directory structure seems to be used and there it work if the .so is in /usr/lib64/python2.7/site-packages and the rest of ruamel.yaml under /usr/lib/python2.7/site-packages. Splitting of the binary in a subpackages is going to make my building for PyPI much simpler as the C source doesn’t change that often, and I don’t have to regenerate all the wheels for the different platforms. (originally posted on 2019-07-22 at 11:12:53)
-
Can you check if https://bitbucket.org/ruamel/yaml/downloads/?tab=downloads contains what you need (for ruamel.yaml, version 0.15.100) and https://bitbucket.org/ruamel/yaml.cmd/downloads/?tab=downloads for ruamel.yaml.cmd version 0.5.4 ? (originally posted on 2019-07-19 at 15:23:39)
-
The %name part is quite flexible, and probably you can not make everyone happy there. openSUSE rpm names are strictly PyPI names ; i.e. ruamel.yaml.convert-0.3.1.tar is their preference. But other distros have different naming conventions, and it doesnt matter much due to %setup -n It is common to use %setup -n tar-ball-name-%version with a literal in the name part because it cant be derived from the rpm name. GitHub tarballs often require this as the repo name is used in the tarball name, and the...
-
Ok, questions: How do I name the tar file? ruamel-yaml-convert-0.3.1.tar (convert all dots to dashes) or ruamel-yaml.convert-0.3.1.tar(i.e. user - repo name) or ruamel.yaml.convert-0.3.1.tar(tarfile named as on PyPI, this has my preference because of consistency, but I am not sure that works for you). I can adapt the top-level directory to match any of those. I have no idea how how many versions I can (and do want to) keep around, so I want to to do some pruning of old uploads. I am thinking of rules...
-
I know how to work around the problem, but the problem remains. The .spec should use standard rpm macros for %setup , otherwise it increases the maintenance costs for each distro. If you dont want to upload tarballs that match %name-%version.tar.gz since BitBucket doesnt do this , the approach I will take is %setup -c mv %name-%version-*/* . rmdir %name-%version-*/ Also note that the URL of the download needs to be in the .spec , and there are tools which check that the stored tarball is the same...
-
If you’re extracting the downloaded tar file anyway, you can do something like: $ U=ruamel $ S=yaml $ V=0.15.100 $ mkdir $U-$S-$V $ curl -s https://bitbucket.org/$U/$S/get/$V.tar.bz2 | tar xj --strip-components=1 -C "$U-$S-$V" to get things extracted directly into a directory ruamel-yaml-0.15.100, with `_test` subdir etc You can probably achieve the same with Gnu-tar's --transform but then you would need to know the name of the initial path segment. (originally posted on 2019-07-17 at 14:07:50)
-
Bitbucket downloads, now that is a novel idea ( https://bitbucket.org/ruamel/winpysetup/downloads/ ). The docter said something about …heimer, I have forgotten exactly what it was. :-) (originally posted on 2019-07-17 at 10:21:41)
-
Why not use BitBucket "downloads"? IIRC you can upload custom tarballs there. That avoids the ruamel-yaml-25737c624a8c directory names inside the tarball that BitBucket creates, as it is customary to have the directory name inside the tarball be ruamel-yaml-%version re moban, I usually have a .moban.yaml inside the repo, but then that is all that is needed, and then I can regenerate all files to ensure the repo is in sync, and also generate other per-repo files which other tools might need that can...
-
As for the download problems, it is probably easier if I make a “full” tar file, including tests, automatically and put that on my server for you to download. I would give you a secret, non-guessable, base url and when you see a new version on PyPI (or github or whatever way you now know to rebuild your RPM), get ruamel.yaml.cmd-X.Y.Z.tar.xz (et other relevant packages) from there. If I put that in my develop command depending on __init__.py, that will be automatically available in time. (originally...
-
Apart from using setup.py as a template, my philosophy is to minimize the “crap” in my Python projects, i.e. reducing the number of files needed in a module by generating them on the fly from data loaded (not eval-ed) from the one file you need to have anyway (``__init__.py``) and not having subdirectories called ``src`` or ``lib`` that prevent you from having a normal source tree on which you can use standard python imports. My initial reaction is to I think that adding a `mobanfile` to the projects...
-
No rush. I can grab tarballs from bitbucket with the tests, but a bitbucket URL in a .spec doesnt look as good as it used to. And https://bitbucket.org/ruamel/yaml.convert/get/0.3.1.tar.gz has a tarball which expands to ruamel-yaml.convert-9400b6b23cda/* which isnt as nice as githubs archives, and makes the .spec a little less standardised. Maintainers are less likely to want to have to find the new tarball here. On all your templates and setuptools hackery, I would be keen to import all your setup.py...
-
I can see that that would make things easier for packagers, and with most "normal" users of PyPI using the .whl files, in which I don't want to include the tests, I consider it less problematic to include tests in the .tar.gz version. If I can easily (i.e. automatically) differentiate these two given my development tools, I might consider doing that, but I am also considering moving all tests to sub-packages and I am not sure I want to support both. Please be aware that my development tool, when...
-
I can split of the binary stuff in a seperate package ( ruamel.yaml.ext ) that only generates the .so, the base package would be dependent on that, but would be arch independent (and it works without the .so as well). That way there would be no (additional) arbitrary rule, things would just operate as before, but because ruamel.yaml would be under /usr/lib/python3.7 together with the rest leaving ruamel.yaml.cmd and .convert as is should work. I would want to make sure the loading of the .so from...
-
For loading the .so, since they are directly under the site-packages, i don’t think that that Python needs a .pth file. Correct. My first submitted solution removed all the .pth files, and it worked well. Would it help to make two RPMs from ruamel.yaml? One with only the arch dependent .so and the other with non-arch stuff. I've considered that, but I suspect then I will get in more trouble with openSUSE maintainer for another arbitrary rule which isnt written down anywhere. So first step for me...
-
It has been a few years, but IIRC the problem with the .pth files was caused by having namespace packages in a "normal" setup.py that are nested. So you can have abc.x and abc.y but not abc.x.z (the latter of course works fine if you have everything together in one tree). If you load abc.x.z it matches with the .pthfile of abc.x and then tries to find the corresponding subdirectory in its installation. This is most likely also the cause of not finding `ruamel.yaml` as either ruamelis not found in...
-
The sitelib is always /usr/lib/python3.7 for py37 , and the archlib is usually something like /usr/lib64/python3.7 or /usr/lib32/python3.7 . I don't understand the complete rationale for splitting them. I doubt it is to save space. When pip/setuptools/etc are installing, if there is any arch-dependant files in the package, they put all the files (inc .pyc) into archlib, otherwise they put them into sitelib. So all of the files of .yaml and .ordereddict are put into archlib. But then when installing...
-
Although I can understand that you want to have /usr/lib64/python3.7, /usr/lib32/python3.7 and /usr/lib32/python2.7 , etc., because of incompatibilities both in shared libraries a package might have , I don't see how much it helps or saves much to have common ``.pyc`` for 3.7 under /usr/lib/3.7. Is there a 32 bit version built in the first place? I would tend to “solve” this by making all the packages arch specific when building on OpenSuSE. Are you available to potentially discuss this issue in...
-
^ that problem is very likely to be the cause of errors like https://bitbucket.org/ruamel/yaml.cmd/issues/5/import-error-running-yaml The yaml namespace only contains convert and cmd, so YAML cant be found. (originally posted on 2019-07-15 at 13:58:56 by John Vandenberg <John Vandenberg@bitbucket>)
-
Something to be aware of, your ruamel/* packages create a problem for Python installations which have binaries in a separate site-packages than the non-arch packages. i.e. setuptools puts ruamel/yaml into /usr/lib64/python3.7/site-packages/, but it puts ruamel/yaml/convert into /usr/lib/python3.7/site-packages/. Then importing ruamel.yaml loads from /usr/lib/python3.7/site-packages/ , and cant find the yaml library in lib64 because it is shadowed and Python does not merge namespaces between the two....
-
I've used and recommended your yaml package for a long time, and I have travis py38-dev jobs which blew up on me. Today I want to use your yaml.cmd, but I've come to a position where I am now refusing to install stuff that is not distro-packaged properly. openSUSE 's open build system is very nice for this; it is almost too easy, and there the Python RPM system automatically builds for py2.7 and py3.x, where py3.x is py3.7 & py3.6 and py3.4 depending on the target distro version, so I usually see...
-
status set to closed wfm (originally posted on 2019-07-12 at 07:49:27 by John Vandenberg <John Vandenberg@bitbucket>)
-
Yes as they all use the same setup.py, driven by data in __init__.py, (see my comment on my issue #2), but not all packages are rebuild and re-submitted to PyPI on every addition to setup.py, for these kind of bugs caused by changes in the internals I should of course do so. Since you also submitted https://bitbucket.org/ruamel/yaml/issues/296/another-python-38-dev-compilation-breakage, Are you systematically testing all (my) packages on PyPI with multiple Python versions? (originally posted on 2019-07-12...
-
I'll retest. Note I encounter the same problem with ruamel.std.pathlib , and likely others in that garden. (originally posted on 2019-07-12 at 07:31:12 by John Vandenberg <John Vandenberg@bitbucket>)
-
status set to resolved Thanks for reporting, this was caused by an incompatibility in newer setuptools/distutils. Not sure why this was not automatically resolved with this commit. If this indeed resolves the issue, please close it using the Workflow pull-down. (originally posted on 2019-07-12 at 07:23:01)
-
ruamel.yaml.convert released /ruamel.yaml.convert-0.3.2.tar.xz
-
1
