[libtorrent] No .msi installers since 1.0.9

[Łukasz Taczuk]

Hello,

since the release of libtorrent-1.0.9 in February, there have been no
releases with their respective python-libtorrent-1.x.x.win32.msi installers.
Also, I noticed that while fixing #736 (https://github.com/arvidn/
libtorrent/pull/736/commits) artifacts have been removed from AppVeyor
builds.

From that point on, the only way to have a python library working is to

compile it yourself.
What were the reasons for stopping releasing the python bindings and what
would be required to have them be released again?

Also, on another note, releasing it as python wheels would make it MUCH
easier to install, as one would have to just do a pip install libtorrent to
have a working installation.

[Łukasz Taczuk]

Hi,

is there a way to help you start releasing msi installers for
python-libtorrent again?

Post by Łukasz Taczuk
Hello,
since the release of libtorrent-1.0.9 in February, there have been no
releases with their respective python-libtorrent-1.x.x.win32.msi installers.
Also, I noticed that while fixing #736 (https://github.com/arvidn/lib
torrent/pull/736/commits) artifacts have been removed from AppVeyor
builds.
From that point on, the only way to have a python library working is to
compile it yourself.
What were the reasons for stopping releasing the python bindings and what
would be required to have them be released again?
Also, on another note, releasing it as python wheels would make it MUCH
easier to install, as one would have to just do a pip install libtorrent to
have a working installation.
--
Lukasz Taczuk

[Arvid Norberg]

Post by Łukasz Taczuk
Hi,
is there a way to help you start releasing msi installers for
python-libtorrent again?

Yes. You could experiment with a pull request against the RC_1_0 (or
RC_1_1) branch to enable building the python package on appveyor again.

If I recall correctly, something in the python package build started
failing. I'm also not sure which version of msvc python modules are
supposed to be built with, for ABI compatibility. This is especially
important in upstream versions, RC_1_1 or master, where msvc-9.0 is no
longer supported. That used to be the required msvc version for python
modules.

If you submit a pull request, a build will be triggered on appveyor every
time you push a new update to it. You probably need to update the
appveyor.yml file to indicate where the artifact is output as well.

[Łukasz Taczuk]

I'll take a look.
I cloned the repository and set up my own AppVeyor project because I would
first want to find where exactly the build started failing, which is not
easy to figure out by looking at your AppVeyor results, due to the fact
that most of the builds were "cancelled by the user". I don't want you to
needlessly receive notifications each time I make a change.

What are (were?) the differences between the test_debug and test_barebones
variants in AppVeyor? They seem to mean something different and have
different setup depending on the branch.

Post by Arvid Norberg

Post by Łukasz Taczuk
Hi,
is there a way to help you start releasing msi installers for
python-libtorrent again?

Yes. You could experiment with a pull request against the RC_1_0 (or
RC_1_1) branch to enable building the python package on appveyor again.
If I recall correctly, something in the python package build started
failing. I'm also not sure which version of msvc python modules are
supposed to be built with, for ABI compatibility. This is especially
important in upstream versions, RC_1_1 or master, where msvc-9.0 is no
longer supported. That used to be the required msvc version for python
modules.
If you submit a pull request, a build will be triggered on appveyor every
time you push a new update to it. You probably need to update the
appveyor.yml file to indicate where the artifact is output as well.
--
Arvid Norberg
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss

[Łukasz Taczuk]

Okay, so I think I'm going to have to compile everything manually anyway
because at one point, the bindings just stopped being generated on master
(a7213d3f5a9d752ce6c6521d8eb89a5d50d95947) even after manually addiing
"python_package: 1" and I don't really know why by just looking at
AppVeyor's output.

Also, when I checked the current appveyor.yml file, I couldn't help but
notice that there is only talk of python 3 x86_64 there ("we use 64 bit
python builds").

This prompts the question:
1) Is python 2 still supported on master?
2) Is python 2 32-bit still supported on master?

Or does appveyor.yml contents just happened to be like what they are and it
doesn't mean anything for python 2 32-bit?

Post by Łukasz Taczuk
I'll take a look.
I cloned the repository and set up my own AppVeyor project because I would
first want to find where exactly the build started failing, which is not
easy to figure out by looking at your AppVeyor results, due to the fact
that most of the builds were "cancelled by the user". I don't want you to
needlessly receive notifications each time I make a change.
What are (were?) the differences between the test_debug and test_barebones
variants in AppVeyor? They seem to mean something different and have
different setup depending on the branch.

Post by Arvid Norberg

Post by Łukasz Taczuk
Hi,
is there a way to help you start releasing msi installers for
python-libtorrent again?

Yes. You could experiment with a pull request against the RC_1_0 (or
RC_1_1) branch to enable building the python package on appveyor again.
If I recall correctly, something in the python package build started
failing. I'm also not sure which version of msvc python modules are
supposed to be built with, for ABI compatibility. This is especially
important in upstream versions, RC_1_1 or master, where msvc-9.0 is no
longer supported. That used to be the required msvc version for python
modules.
If you submit a pull request, a build will be triggered on appveyor every
time you push a new update to it. You probably need to update the
appveyor.yml file to indicate where the artifact is output as well.
--
Arvid Norberg
------------------------------------------------------------
------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Libtorrent-discuss mailing list
https://lists.sourceforge.net/lists/listinfo/libtorrent-discuss

--
Lukasz Taczuk

[Arvid Norberg]

Post by Łukasz Taczuk
Okay, so I think I'm going to have to compile everything manually anyway
because at one point, the bindings just stopped being generated on master
(a7213d3f5a9d752ce6c6521d8eb89a5d50d95947) even after manually addiing
"python_package: 1" and I don't really know why by just looking at
AppVeyor's output.
Also, when I checked the current appveyor.yml file, I couldn't help but
notice that there is only talk of python 3 x86_64 there ("we use 64 bit
python builds").
1) Is python 2 still supported on master?

Yes. But iirc, there were some difficulties getting the appveyor build to
work in python 2.

Post by Łukasz Taczuk
2) Is python 2 32-bit still supported on master?

Yes, as far as I know, there isn't anything preventing a 32 bit build, or
any other configuration really.

Post by Łukasz Taczuk
Or does appveyor.yml contents just happened to be like what they are and it
doesn't mean anything for python 2 32-bit?

If you think there's significant risk of accidentally breaking 32 bit
builds without noticing (i.e. the 64 bit build still works), it may make
sense to build and test both. I don't think that risk is that great though,
and it would add a lot of time to appveyor jobs completing.

[Arvid Norberg]

Post by Łukasz Taczuk
I'll take a look.
I cloned the repository and set up my own AppVeyor project because I would
first want to find where exactly the build started failing, which is not
easy to figure out by looking at your AppVeyor results, due to the fact
that most of the builds were "cancelled by the user". I don't want you to
needlessly receive notifications each time I make a change.
What are (were?) the differences between the test_debug and test_barebones
variants in AppVeyor? They seem to mean something different and have
different setup depending on the branch.

There may be some slight difference in master and RC_1_1. Those
configurations are defined in the Jamfile. They don't really need to be
anymore though, I put them there to create shorter paths for the build
products on windows (which has a pretty short limit on paths). Now it's all
building with --hash though, which means the build configurations for the
CI could really be moved out into the .travis and appveyor files.

However, for building packages, you shouldn't use either of those
configurations. Take a look at the setup.py file in the binding, it can
build libtorrent with boost-build (bjam) and it specifies "release" and
"optimization=space" iirc.