Make a pre-release or backport

[Wrzlprmft]

Since this feature request was implemented, I migrated my modules JiTCODE, JiTCDDE, and JiTCSDE to from using SymPy to SymEngine for symbolics and C code printing. The outcome is truly awesome: Previously, the duration of the code-generation step was a major drawback of these modules. Now, it is sped up by a factor of up to nine hundred, making it negligible in most situations. (Thank you!)

Except for overhauling the documentation and some unrelated changes, I am finished with the new versions. Therefore, I am confident that I have no further needs for changes to SymEngine. Now, when I release the new version, it would be great if my users didn’t have to bother with building and installing SymEngine and SymEngine.py by hand, but could pull it directly from PyPI as a requirement. Would it be possible to make a pre-release, new release, or similar including this commit to PyPI?

[isuruf]

Glad to hear that you got a nice speedup when switching to symengine.
We can certainly generate wheels for you. It's automated at https://github.com/symengine/symengine-wheels. I don't know how pre-release versions can be uploaded to PyPI. We might need to use versioneer to version the dev packages.

cc @certik

Btw, you might be interested in #201

[Wrzlprmft]

I don't know how pre-release versions can be uploaded to PyPI.

Going by this, it seems to be just a matter of choosing a proper version tag and it will be ignored by default as a dependency. Only thing I have to hope for is that I can still depend on it as an explicit dependency. PS: I just tested this with a random pre-release and it worked.

Btw, you might be interested in #201

Sadly, no. Scipy ODE does not support LowLevelCallable (and I will rather implement my own ODE integrators before touching it). Anyway, right now I am using Lambdify only as a fallback option in case proper compilation fails.

[Wrzlprmft]

@isuruf @certik Sorry to bother you, but is there any news on this matter? I am ready for a release and all that is missing is a version number for the SymEngine dependency.

[certik]

@Wrzlprmft sorry, I missed this issue before. I am glad you found such a big speedup, that's precisely why we created SymEngine.

@isuruf why not to just make a regular release?

[isuruf]

@certik, sure, but that's going to take a while though. We have to make a release for symengine first.

[Wrzlprmft]

@isuruf @certik Sorry to bother you again, but can you give me a prognosis when to expect the release? I am asking because I have a paper on my software ready to submit to a journal (preprint). For this it would be advantageous (though not required) if I could refer to proper version numbers and reviewers could easily install the software.

I don’t know whether this would make it easier for you, but for my purposes it would suffice if the pull requests #1343 and #1357 would be backported to the last release (0.3.0).

[isuruf]

@Wrzlprmft, I've created this milestone for symengine (C++) 0.4.0 (already expired), https://github.com/symengine/symengine/milestone/4, but I haven't had time to look at them.

@certik, what do you think about updating pypi wheels with symengine patched. I don't think we even need to update symengine.py version, as the patches needed are in the C++ library. Or we can make a 0.3.1 update for symengine.py.

[certik]

@isuruf why don't we release 0.3.1. Besides tagging, what needs to be done to release? Do we have it documented somewhere?

[isuruf]

Tagging which library? symenigne 0.3.1 or symengine.py 0.3.1

[certik]

Do we have different release numbers for each library, or do they have the same number always? (I meant to tag both and release both with the same number.)

[Wrzlprmft]

I don't think we even need to update symengine.py version

@isuruf How could I properly declare the updated PyPI package as a dependency then? And how would you even distinguish the new and the old one on PyPI?

[certik]

@Wrzlprmft Let's make a release, then you can simply specify the version number in your article.

[Wrzlprmft]

Fine with me. Note though that the article won’t have to specify a SymEngine version number. It’s the PyPI packages of my modules that have to specify a working dependency (with all the features I need). (I can then claim in my paper that my modules are easily installable.)

[Wrzlprmft]

@isuruf @certik: Any progress or plans in this respect? I already got a handful of support requests from people who somehow failed to build the right version of SymEngine – not that it’s difficult, but it’s nothing my typical user is good at. And as you may know, for every person reporting an issue, there are several who don’t.