We have a project the also contains OpenAPI documentation. Up until now we had that connected to a Netlify site that would build the docs using redoc-cli and would publish it on Netlify.
The project also contains a Pipfile as the rest of the project is in Python.
The way the Netlify build image works is that it pulls the code and immediately tries to handle a Pipfile if it exists.
Up until recently, we had no problems as we used Python 3.7 which is part of the 16.04 build image. We have recently moved to Python 3.8 and now we can’t let the Netlify build work because it fails due to the existence of the Pipfile (which we don’t even use during build).
Is there a way to tell the build image to ignore the existence of the Pipfile?
I was considering adding a command in Netlify to delete it but the detection of it and trying to use it runs before we get to a point where our command line runs.
Hmmm… I don’t currently know of a way to “tell the build image to ignore the existence of the Pipfile.”
It does look like there’s an open PR to add PYTHON_VERSION support in our UI and netlify.toml:
It probably wouldn’t hurt to chime in there voicing support for the feature and/or asking specifically about 3.8.
Can you share a repo by any chance? Achieving what you want by deleting the file before build (in your build command) or rearranging your directories to only build a specific one seems like it should be possible.
Unfortunately, this will not work The main reason is that as part of setting up the build environment, the build-image detects the Pipfile and tries to install files from it, so it fails before it reaches the point where it runs the build command and can remove the Pipfile.
I was looking at using Build Plugins, but those, as well, run after the build-image sets up itself.
I think the best solution would be to add Python 3.8 support as well as an environment variable that allows setting up a specific Python version, the same way Node and others work.
Ahh, I did worry that that would be the case! And you’re right with regards to build plugins, too.
What we can do is, well… a couple of things! I’ve created an issue in the build-image repo to add Python 3.8 support. I’d love your input on this so, please, if you could contribute to the issue with your pipfile (which the team could then use as part of integration testing) that would be great!
In the meantime, we can at least see if 3.8 will work. Have you tried adding a runtime.txt file? This is analysed before the pipfile during the build process.
I think you’d only be able to put 3.7 into runtime.txt btw! We are just hoping that will be “closer enough” that your pipfile won’t cause the build to fail as 2.7 does now. I realize this is not a great workaround if it works, but it is what we have available today…
Actually, we have a Pipfile that requires 3.8 and the problem is that when the build image detects a Pipfile it tries to run pipenv install which fails because there is no Python 3.8 available.
In my case, an environment variable to stop the code from detecting Pipfile or a “Post code pull” hook could have made it easy for me to skip the pipfile check or remove the Pipfile before the build system detects it.
@peachfinance, did you have a chance to try setting the Python version in runtime.txt? I reviewed this post and want to add that checking runtime.txt takes priority over the pipfile in our build system. You should be able to set a supported version in runtime.txt in order to avoid checking the pipfile.
It won’t work since the Pipfile we have there (which we don’t even want to process) requries 3.8.
This is the same project that has some API docs we publish using redoc-cli and its the same project as the backend that uses the same OpenAPI schema files. We don’t need the Pipfile processing at this point but Netlify does that and there is a) no way of avoding it and b) there is no support for Python 3.8 so it just failes.
Can you change the base directory in your Netlify site settings so the build runs from a directory that doesn’t have a Pipfile in it? I am not familiar with redoc-cli and how flexible it is for specifying where the source content is.