If the project code itself needs run-time access to the version, the simplest way is to keep the version in both setup. These values will be displayed on PyPI if you publish your project. On pypi. Classifiers exist for all major open-source licenses. The license argument is more typically used to indicate differences from well-known licenses, or to include your own, unique license.
Provide a list of classifiers that categorize your project. List additional relevant URLs about your project. This is the place to link to bug trackers, source repositories, or where to support package development.
The string of the key is the exact text that will be displayed on PyPI. Set packages to a list of all packages in your project, including their subpackages, sub-subpackages, etc.
Although the packages can be listed manually, setuptools. Use the include keyword argument to find only the given packages. Use the exclude keyword argument to omit packages that are not intended to be released and installed. When the project is installed by pip , this is the specification that is used to install its dependencies. Support for this feature is relatively recent. In addition, only versions 9.
Often, additional files need to be installed into a package. The value must be a mapping from package name to a list of relative path names that should be copied into the package. The paths are interpreted as relative to the directory containing the package. For more information, see Including Data Files from the setuptools docs. It is mostly useful if you need to install files which are used by other programs, which may be unaware of Python packages. Each directory, files pair in the sequence specifies the installation directory and the files to install there.
Each file name in files is interpreted relative to the setup. For more information see the distutils section on Installing Additional Files. So, if your project uses setuptools , you must use pip to install it. Alternatively, if you must use python setup. Use this keyword to specify any plugins that your project provides for any named entry points that may be defined by your project or others that you depend on.
For more information, see the section on Advertising Behavior from the setuptools docs. You can then let the toolchain handle the work of turning these interfaces into actual scripts 2. The scripts will be generated during the install of your distribution. For more information, see Automatic Script Creation from the setuptools docs. Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible public version scheme specified in PEP in order to be supported in tools and libraries like pip and setuptools.
To further accommodate historical variations in approaches to version numbering, PEP also defines a comprehensive technique for version normalisation that maps variant spellings of different version numbers to a standardised canonical form. For new projects, the recommended versioning scheme is based on Semantic Versioning , but adopts a different approach to handling pre-releases and build metadata. Y requires at least release X. Python projects adopting semantic versioning should abide by clauses of the Semantic Versioning 2.
Semantic versioning is not a suitable choice for all projects, such as those with a regular time based release cadence and a deprecation process that provides warnings for a number of releases prior to removal of a feature. A key advantage of date based versioning is that it is straightforward to tell how old the base feature set of a particular release is given just the version number.
Version numbers for date based projects typically take the form of YEAR. MONTH for example, This is the simplest possible versioning scheme, and consists of a single number which is incremented every release. While serial versioning is very easy to manage as a developer, it is the hardest to track as an end user, as serial version numbers convey little or no information regarding API backwards compatibility.
Combinations of the above schemes are possible. It's just an alternative to a source distribution or Windows executable, but it should be noted that for pure Python, the egg file is completely cross-platform.
We will take a look at how to create our own egg using the package we created in a previous tutorial. Create a new folder and put the mymath folder inside it.
Then create a setup. Note that instead of using Python's distutils' setup function, we're using setuptools' setup.
To create said egg, you'll need to do the following from the command line:. This will generate a lot of output, but when it's done you'll see that you have three new folders: build, dist, and mymath. The only one we care about is the dist folder in which you fill find your egg file, mymath Note that on my machine, it picked up my default Python, which was 2.
The egg file itself is basically a zip file. Personally, I've had few issues with it and don't mind using it. I suggest you use PEP , or disable isolation with --no-build-isolation , if you have a build-time dependency. Yes it does! From what is written see my quote in the first message of the issue , the example in this issue should work.
It's clear. I have to repeat that PEP pyproject. Using --no-build-isolation leads to the same result as without pyproject. A simple solution would be that pip installs each wheel that has to be installed just when it is ready before the next build and not at the end, when all wheels have been built.
What is the problem of doing that? I know. I try to tell you that there is a problem with the new standard pyproject. If there a problem with my English? Why don't you understand me? Isn't it clear that if we take seriously what is written in this paragraph, the example in this issue should work. I have to admit that I am sad about how my remarks this issue and issue are treated. In scientific and data applications, conda is used a lot. My reasoning is that it is not a great thing that the Python community is split in terms of installation tools, so I tried a lot to be also able to work without conda.
I thought that pip could also be adapted for our applications. But now, I start to see how concerns from my community are treated by pip core developers. Those terms are possibly a little confusing they confuse me! There's no implication here or anywhere else that a runtime dependency will automatically be available as a build dependency. Since PEP support in pip introduced build isolation, clearly understanding the distinction is crucial if you expect your build step to work properly.
But that means you have to use pyproject. But before pyproject. All I can say is that we're trying. Personally, I'm struggling to understand what you want and why the approaches that have been suggested to you are so unacceptable.
I will say that "because conda needs pip to work like this" is not a compelling argument, at least to me. What's needed is a better understanding of the shared requirements of the two ecosystems and how both tools can compromise to make things work better - while still remaining true to their core goals and user communities.
But I don't understand that code so I might be wrong, and even if I'm not that's something specific to setuptools, not anything that pip is involved with.
Let's improve the wording in the documentation. I think that's the reason for the confusion in this case. But the same use case no longer works with the "new" first build wheel, then install from wheel installation. Unfortunately, pyproject. It's clear to me that this was meant to work the way that we're expecting it to work.
0コメント