google-deepmind / lab2d

A customisable 2D platform for agent-based AI research

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Support pip installation and show the working pip command in the Readme

cool-RR opened this issue · comments

This would be very useful for https://github.com/deepmind/meltingpot as well, so that it can also be provided as a package

We have a build rule that produces a wheel file; you can install that with pip install. Do you think that needs additional documentation?

@tkoeppe Depends on how much you care about ease of use. Ideally, you'd regularly update the wheel file to PyPI so people could install lab2d normally like any other Python package rather than have to build a wheel. If this isn't a high enough priority for you, then documentation for making the wheel would be good.

I'm not sure we would want a new wheel on PyPI for every single commit here. And for the tagged releases we already build wheels automatically, so you can just download one from the releases page. So I suppose the ability to build a wheel file isn't actually all that relevant to most users.

Not sure where the idea of a new wheel on PyPI for every commit came from. Think of any normal Python package you install, like numpy or requests. They have a process for uploading their wheel to PyPI so you could install them using pip install numpy requests. They certainly don't upload every commit to PyPI.

Providing the wheel on the releases page is better than not providing it at all. It still makes it difficult for other package maintaners to depend on lab2d, because Pip's automatic dependency resolution can't fetch the wheel from your releases page. Therefore, every package that uses lab2d has to tell its users to go and find that wheel manually.

However, I understand that the standard for user friendliness for research-related packages is lower than most of the open-source world, and I understand if this isn't a priority for you.

However, I understand that the standard for user friendliness for research-related packages is lower than most of the open-source world, and I understand if this isn't a priority for you.

Could we please have this conversation without the passive-aggressive tone? This seems neither necessary nor helpful.

Oh, I'm really sorry, no passive-agressive tone was intended here! I really meant what I said, and let me explain.

Most of the code that I see in papers, from various instituions, has a low standard for user friendliness. I'm an engineer with lots of open-source experience, making my first steps in the research world, and I noticed that the standard for how easy the code is to work with is lower in the research world. Many times when I see code that's linked from a research paper, there are no instructions on how to run it, and when I try to run it, there are exceptions, then I have to report them and do back-and-forths with the maintainers, if they even have time... This is frustrating, but I accepted that this is how it is. It's not a priority for researchers to create a very friendly software package, they are judged based on the papers they write.

The fact your package even has the wheels available, already makes it more friendly than the average piece of research code. I'm suggesting how to take it to the next level to be on par with such packages like numpy and requests. However, I said what I said to acknowledge that this might not be a priority for you, and I think it's valuable to set these stretch goals in case you, or anyone else in the future would like to improve the user experience of this package.

Sorry for any unpleasantness caused.

Thanks, no worries, I appreciate it!

I suppose there's a question of what the appropriate "standard" is here. We definitely don't have regularly staffed support for lab2d, and the contributors chip in only when they happen to have some time or when there's some particular reason. So don't want to create the impression that this is a regularly maintained package, and I don't know if such expectations would be attached to a PyPI entry. @jagapiou has been looking into this, though, and I'm certainly not opposed. I merely thought that what we're offering is already fairly close to that (just one additional download step before you call pip) that it wasn't a big problem.

I understand the benefit of automated dependency management, but do consider that in two years' time we might not have released a new wheel and your base glibc dependencies have moved on and now the wheel on PyPI is no longer compatible, then you have a whole different kind of frustration. So rather than trying to promise something that I can't be sure we can keep, I was keeping it conservative and only wanted to offer something reasonably self-contained.

But I think @jagapiou might be the best person to talk about this.

We are working on our side to have at least some versions available in pypi so it can be pip installed. Stay tuned

Heya, yep I'm working on this, so feel free to assign to me. The wheels are great but the correct wheel to install must be manually specified and can't currently be autodetected. So automatically uploading to pypi when we make a release should be easy. I'll have a PR for this very soon.

Hi all, appreciate the hard work getting this up on pypi, I'm having some installation issues with MacOS though--when I try to install via pip I get this error:

pip install dmlab2d
ERROR: Could not find a version that satisfies the requirement dmlab2d (from versions: none)
ERROR: No matching distribution found for dmlab2d

I tried downloading the wheel manually but ran into errors with that as well:

ERROR: dmlab2d-1.0.0_dev.10-cp310-cp310-macosx_12_0_x86_64.whl is not a supported wheel on this platform.

For context about my environment:

sw_svers
ProductName:	macOS
ProductVersion:	12.4
BuildVersion:	21F79`)
python --version
Python 3.10.10
>>> import platform
>>> platform.architecture()
('64bit', '')
>>> platform.mac_ver()
('10.16', ('', '', ''), 'x86_64')

Maybe my python thinks my mac version is different than it actually is? Usually wheels are for any mac version so haven't had this issue but it could very well be a personal issue with my environment.

@jagapiou Wasn't there something about needing some environment variable on macOS to disable some kind of version checking?

@elliottower For macOS, try setting SYSTEM_VERSION_COMPAT=0 (see actions/setup-python#279).

SYSTEM_VERSION_COMPAT=0 pip install dmlab2d

dmlab==1.0.0 is now up on PyPI. README update coming soon.

@elliottower: does setting the environment variable help?

Hi I'm using ubuntu linux on arm64,
I'm trying to install dmlab but it doesn't work.
error:
ERROR: Could not find a version that satisfies the requirement dmlab2d (from versions: none)
ERROR: No matching distribution found for dmlab2d

@AllenChienXXX What do you mean by "trying to install" -- do you mean with pip? (Generally, could you please give some details in questions?)

I don't think we're providing any precompiled wheels for Linux/arm64, but it should be possible to build the wheel from source. I'm not sure if we've tested that combination, but at least in principle all the necessary settings should be available (esp. in LuaJit, but in a crunch you can build with Lua 5.1).

The original issue is now fixed I believe. Please open new issues if the pip install isn't working.

I tested pip installation now and it works. Thank you!