Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide `wheel` distribution #1734

Closed
spooning opened this issue Jun 30, 2014 · 15 comments

Comments

@spooning
Copy link
Contributor

commented Jun 30, 2014

Originally submitted to Google Code by @pekkaklarck on 17 Jun 2014

RF 2.8.5 added possibility to create wheels (http://wheel.rtfd.org/, #1674). Unfortunately the wheel we initially uploaded to PyPI broke installation with pip on Windows and needed to be removed. The reason was that our setup.py controls which start-up scripts to create and with wheels setup.py is not executed.

In RF 2.9 we should take a new look at this. Most likely it requires making changes to how start-up scripts are created. An important task is also documenting wheel support.

@spooning spooning added this to the 2.9 milestone Jun 30, 2014

@pekkaklarck

This comment has been minimized.

Copy link
Member

commented Oct 28, 2014

Providing wheels would require too big changes in RF 2.9. We are already planning to drop separate Windows installers away in RF 3.0, and then we could switch to wheels too.

@pekkaklarck pekkaklarck removed this from the 2.9 milestone Oct 28, 2014

@RonnyPfannschmidt

This comment has been minimized.

Copy link

commented Jun 24, 2015

as far as i can tell, all you would have to do is to add entrypoints for the script names
it would properly work instead of falling over like it does now

what are the big changes needed?

@pekkaklarck

This comment has been minimized.

Copy link
Member

commented Jun 24, 2015

We currently create pybot script for Python, jybot for Jython and ipybot for IronPython. I don't think that's possible with wheels. Creating different start-up script for different interpreters may not be that good idea in general, but that's not something we want to change in 2.9.

@RonnyPfannschmidt

This comment has been minimized.

Copy link

commented Jun 24, 2015

python ironpython and jython have different abi tags, so it seems rather possible to just make wheels with such implementation, however its a bit more of a mess to make those wheels

its indeed uncertain if such a move is a good idea

@pekkaklarck

This comment has been minimized.

Copy link
Member

commented Jun 24, 2015

I think that is a good idea. But it definitely isn't a good idea right now when we want to get 2.9 released in few weeks.

@RonnyPfannschmidt

This comment has been minimized.

Copy link

commented Jun 25, 2015

would it be an acceptable solution to publish such wheels as part of the 2.9 series?

@pekkaklarck

This comment has been minimized.

Copy link
Member

commented Jun 25, 2015

The problem is that if we put a wheel to PyPI, pip will automatically use it. With our custom setup.py that causes broken installations at least on Windows (we've done that). We obviously could put wheels somewhere else, e.g. include them into the release on GitHub, but I doubt anyone will use them. If someone actually wants a wheel, it's always possible to clone the repository, checkout the right tag, and create a wheel with python setup.py bdist_wheel.

@pekkaklarck

This comment has been minimized.

Copy link
Member

commented Dec 23, 2015

The problem with start-up scripts is getting easier now that RF 3.0 introduced new robot start-up script (#2216). I don't think we can remove the old scripts in RF 3.1 yet, though.

@pekkaklarck

This comment has been minimized.

Copy link
Member

commented Feb 13, 2017

Tried to add a zip distro in addition to tar.gz to ease manual installation on Windows (#2542), but it turned out that it's possible to upload only one sdist to PyPI nowadays. If we get wheels working, could consider should we change the sdist format to zip altogether.

@pekkaklarck

This comment has been minimized.

Copy link
Member

commented Apr 26, 2018

pybot and friends won't be supported in RF 3.1 anymore. There shouldn't be any reasons not to use wheels.

@mblakley

This comment has been minimized.

Copy link

commented May 11, 2018

I recently tried running "pip wheel" to generate a local wheel file from my virtual environment (using robotframework 3.0.2), and when I installed the wheel file on a different PC, the robot.bat file contained the full python.exe path from my virtual environment. ex: C:\home\automation\env\Scripts\python.exe -m robot.run %*

I found this out because robot.bat wouldn't run, because the other machine didn't have python in the same path. You probably don't want to use the full path - just assume that python is already on the path.

If someone points me at the file that generates the bat file, and is ok with me making a change, I'll create a PR for this.

@RonnyPfannschmidt

This comment has been minimized.

Copy link

commented May 11, 2018

there is a reason why wheels generate exe files for the console_scripts entry-point, anything else cant really hope to work correctly

@pekkaklarck

This comment has been minimized.

Copy link
Member

commented May 13, 2018

@mblakley, we actually used absolute paths in *.bathg files on purpose. If we had just used python and you had, for example, C:\Python27, in PATH, running, for example, C:\Python36\Scripts\robot.bat would execute Python 2.7. We could have tried handling that with special variables like %~dp0, but that would have still left some corner cases. As @RonnyPfannschmidt commented, there's a reason why setuptools entry-points create these *.exe wrappers. After #2415 fixed we also use this approach so the problem ought to be finally solved.

pekkaklarck added a commit that referenced this issue Jun 6, 2018
Update distribution formats in INSTALL and BUILD.
- We nowadays provide wheels (#1734).
- Source distribution is nowadays in zip format (#2830).
@pekkaklarck

This comment has been minimized.

Copy link
Member

commented Jun 6, 2018

RF 3.1 alpha 1 has been released as a wheel and it seems to work great!

@pekkaklarck pekkaklarck closed this Jun 6, 2018

@HelioGuilherme66

This comment has been minimized.

Copy link
Contributor

commented Jun 6, 2018

Good to see a 2014 issue resolved :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.