It solves my problem this time. I added pyproject.toml file along with setup.py

Content of pyproject.toml

[build-system]
requires = ["setuptools", "wheel"]
build-backend = "setuptools.build_meta"

It generated .whl file only for that specific package.

If you want to build a wheel correctly, you need build isolation. This means building your wheel in a virtual environment that is isolated from your development virtual environment. This is important as your development environment may have a setup that causes your build to build incorrectly, or contains unstated requirements needed to build your package. With build isolation, you know that anyone, anywhere will be able to build your package.

The two most simple ways of doing this are using the build package, or using the pip wheel command. Do not use python setup.py bdist_wheel. This is a legacy build mechanism that is kept for backwards compatibility of old projects. New projects should not and have no need to use it.

Using pip

pip provides a wheel command which collects and build wheels. It works roughly the same as the build package, except it will collect wheels of dependencies too. You can turn this behaviour off, and build only the current package, by passing the --no-deps flag.

Example usage (if the source root is directory .):

python3 -m venv venv                 # create a virtual environment
./venv/bin/pip install -U 'pip>=23'  # min version of pip required
./venv/bin/pip wheel --no-deps .     # build the wheel

NB. In this example, the virtual environment is not "activated", rather the commands it provides are directly executed. eg. ./venv/bin/pip will execute pip inside (and for) the virtual environment it is a part of.

Using build

build is a simple build tool maintained by the Python developers. It targets users who want to be able to build packages with a minimum of fuss, but wish to use a different package manager to pip. Examples are Linux distributions that have their own package managers (eg. Debian/apt and Red Hat/dnf).

Example usage (if the source root is directory .):

python3 -m venv venv
./venv/bin/pip install build
./venv/bin/python -m build .

PEP 517

In your question, you have supplied a legacy setuptools packaging setup. Both pip wheel and build know how to build this setup. However, PEP 517 aims to modernise python packaging and make it easier for any package manager (eg. pip, uv, poetry, et al.) to build a distribution package. It does this by introducing a file called pyproject.toml that contains standardised configuration data on how to build the package.

Avoid setup.py

Modern and pure-python packages do not need setup.py. They can simply use pyproject.toml to describe their configuration. Using a config file over code-as-config has the benefit that tools are not required to run the code to be able to get a configuration setting. The only remaining use case for setup.py are packages that contain extension modules (modules written in a different language to Python, that are compiled to binary modules, eg. numpy).

Using only pyproject.toml and no setup.py or setup.cfg, your pyroject.tom would look like:

[build-system]
requires = ["setuptools>=70"]  # earlier versions of setuptools also require wheel
build-backend = "setuptools.build_meta"

[project]
name = "package1"
version = "0.1.0"
description = "Package 1"
dependencies = []  # instead of install_requires
requires-python = ">=3.8"

# setuptools-specific config -- other packaging tools can have their own way of
# specifying which python packages make up a distribution package.
[tool.setuptools]
packages = ["package1"]

NB. You can only have one pyproject.toml per directory. So it will not work if you want to be able to build two separate packages from a single root directory. In your case you have both package1 and package2 in your root directory. So you will not be able to build two separate wheels from this directory.