Use the same packaging we use for other projects

[lachmanfrantisek]

Since my comment was ignored, I am creating a proper issue now:

Can we have the same packaging workflow we have for other projects?

• At least for consistency across our projects.
• We agreed on not using Pipenv some time ago..;)
  • Pipenv does not work well with distributions. (Like we already saw.)
  • It can allow us to package this project (Fedora/Copr) to allow usage of the script outside of the team. (We can use packit for that...;-)
  • I am not against revisiting this topic and consider some alternatives like poetry, flitch, hatch,...

[csomh]

Since my comment was ignored, I am creating a proper issue now:

Can we have the same packaging workflow we have for other projects?

dist2src is just a script and it's not packaged at the moment. Is there an immediate need to do so?

• At least for consistency across our projects.

• We agreed on not using Pipenv some time ago..;)

  • Pipenv does not work well with distributions. (Like we already saw.)

Pipenv was my call (back when the script was living in the research repo), just to make it easier to get an isolated environment up and running for the script. I wasn't aware of the decision above.

• It can allow us to package this project (Fedora/Copr) to allow usage of the script outside of the team. (We can use packit for that...;-)

Is there a need for this?

• I am not against revisiting this topic and consider some alternatives like poetry, flitch, hatch,...

[lachmanfrantisek]

Pipenv was my call (back when the script was living in the research repo), just to make it easier to get an isolated environment up and running for the script. I wasn't aware of the decision above.

No problem, that's why I am creating this issue. To let you know and agree as a team.

dist2src is just a script and it's not packaged at the moment. Is there an immediate need to do so? Is there a need for this?

• Some maintainers mentioned that they will be interested in creating (and checking) the generated source-git by their own.
• There are at least people from the team that needs to use it and it's not so convenient to combine Pipenv with distribution packages. (e.g. I hit the same issue as Dominika.)
  • It's fine for playing with the code but not so much if I want to use it as a user. (Like I did during my research.)
• Developer convenience?
  • I need to use a different approach in different projects.
  • It's harder to develop cross-package change with different tooling.
  • • Few general downsides of Pipenv. (Lack of any officiality or support by PSF. Windows-centered. Hard to combine with non-Pipenv packages in IDEs.)