Am 25.01.24 um 20:34 schrieb Miro Hrončok:
$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
...
python-pydyf-0:0.8.0-1.fc40.src
...
weasyprint-0:60.2-1.fc40.src
The packages would probably build fine with flit-core
Indeed, python-pydyf and weasyprint build just fine with flit
I patched python-signature-dispatch[1] and python-vecrec[2] so that they
now use flit-core. I’m glad you pointed out that they were using flit.
[1] https://github.com/kalekundert/signature_dispatch/pull/6
[2] https://github.com/kxgames/vecrec/pull/3
On 1/25/24 15:58, Maxwell G wrote:
On Thu
Am Fr., 26. Jan. 2024 um 09:26 Uhr schrieb Miro Hrončok :
>
> On 26. 01. 24 4:33, Nico Kadel-Garcia wrote:
> > What is the*fascination* with splitting and renaming packages this
> > way?
>
> No idea generally, but in the world of Python packaging,
> the two cases
On 26. 01. 24 4:33, Nico Kadel-Garcia wrote:
What is the*fascination* with splitting and renaming packages this
way?
No idea generally, but in the world of Python packaging,
the two cases I know (poetry, flit) were motivated by folks not wanting to pull
in full-blown package and environment
On Thu Jan 25, 2024 at 20:34 +0100, Miro Hrončok wrote:
> Hello.
Hi Miro,
Thanks for the announcement!
> Now when python-flit-core has been split out of python-flit, I do no longer
> have a use-case for python-flit and hence I have orphaned it.
For context, flit-core is the PEP
Hello.
Now when python-flit-core has been split out of python-flit, I do no longer
have a use-case for python-flit and hence I have orphaned it.
$ repoquery -q --repo=rawhide{,-source} --whatrequires flit
python-perky-0:0.8.2-3.fc39.src
python-pydyf-0:0.8.0-1.fc40.src
python-pyrpm-0:0.14.1-3
s now used for software made by Fedora
Infrastructure these days.
Do we (as in Fedora) have any preference which way, between setuptools,
poetry, and flit?
Not really.
Asking because I'm writing a new tool and I wonder which build system to
use.
If there is a chance you'll ever tar
ra
> Infrastructure these days.
>
Do we (as in Fedora) have any preference which way, between setuptools,
poetry, and flit?
Asking because I'm writing a new tool and I wonder which build system to
use.
Thanks,
--
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.na
On Thu, Dec 23, 2021 at 11:18:47PM +0100, Miro Hrončok wrote:
> On 23. 12. 21 21:10, Michel Alexandre Salim wrote:
> > I'm starting to try and grok pyproject.toml and its assorted PEPs in
> > more details, and it looks like flit is one of the more straightforward
> > way
On 23. 12. 21 21:10, Michel Alexandre Salim wrote:
I'm starting to try and grok pyproject.toml and its assorted PEPs in
more details, and it looks like flit is one of the more straightforward
way to build compliant wheels out there.
So is setuptools BTW.
Should we get it into EPEL9? I
lim <
sali...@fedoraproject.org> wrote:
> I'm starting to try and grok pyproject.toml and its assorted PEPs in
> more details, and it looks like flit is one of the more straightforward
> way to build compliant wheels out there.
>
> Should we get it into EP
I'm starting to try and grok pyproject.toml and its assorted PEPs in
more details, and it looks like flit is one of the more straightforward
way to build compliant wheels out there.
Should we get it into EPEL9? I filed a tracking bug:
https://bugzilla.redhat.com/show_bug.cgi?id=2035376
Hello everyone,
python-flit was updated to version 3.0.0 in rawhide. Flit now requires
metadata in pyproject.toml file instead of flit.init. We have fixed 2 Fedora
packages affected by this change so there is no action needed from your
side. This is just a heads up in case you will use Flit in
On Sat, Nov 18, 2017 at 5:28 AM, Nick Coghlan wrote:
>
> Ah, OK - this makes sense.
>
> Framing it in terms of the required input file, the two most suitable
> names would be:
>
> * "pyproject.toml compatible spec files"
> * "setup.py only spec files"
>
> I'd suggest keeping the current wheel-cent
On 18 November 2017 at 06:54, Toshio Kuratomi wrote:
> On Thu, Nov 16, 2017 at 8:43 PM, Nick Coghlan wrote:
>> Switching to a wheel based build doesn't change either the starting
>> point (which is still an sdist) or the end point (which is still a
>> policy compliant RPM), it changes the interna
On Thu, Nov 16, 2017 at 8:43 PM, Nick Coghlan wrote:
> On 17 November 2017 at 11:55, Toshio Kuratomi wrote:
>>
>> On Thu, Nov 16, 2017 at 5:37 PM, Nick Coghlan wrote:
>> > So the two possible approaches are:
>> >
>> > * traditional sdist: "setup.py build", "setup.py install"
>> > * Current wheel
On 17 November 2017 at 11:55, Toshio Kuratomi wrote:
>
> On Thu, Nov 16, 2017 at 5:37 PM, Nick Coghlan wrote:
> > So the two possible approaches are:
> >
> > * traditional sdist: "setup.py build", "setup.py install"
> > * Current wheel macros: "setup.py bdist_wheel", "pip install "
> >
> > If we
umentation, it doesn't appear that wheels are even central to
>> it (contrast how much wheel is mentioned in its documentation compared to
>> pyproject.tom). Instead I would emphasize flit itself as the build tool
>> which we're using to transform the source into the f
On 17 November 2017 at 04:50, Jason L Tibbitts III
wrote:
> Note also that the guidelines are in the wiki for convenience, but
> there have been at least two efforts to move them to a "better" format.
> And I would truly love to have a companion set of documents which aren't
> guidelines but whic
quot;
> * "Defining an RPM based on a setup.py file"
>
>
> I would not emphasize the use of wheel files as they are not source and
> from flit's documentation, it doesn't appear that wheels are even central
> to it (contrast how much wheel is mentioned in its d
> "TK" == Toshio Kuratomi writes:
TK> However, you should check with tibbs/FPC about
TK> whether the definitions/list of macros are an altogether dated
TK> concept.
I think it's reasonable to document macros which are going to need to
use. Python packaging just isn't sufficiently regularize
> "NC" == Nick Coghlan writes:
NC> Even though it's just a new informational link, I'm guessing we
NC> still need to file an FPC ticket for that?
You can just ask me for super minor things, but it does sound like this
could use a bit of exposition in the guidelines, and that would at least
n
I would not emphasize the use of wheel files as they are not source and
from flit's documentation, it doesn't appear that wheels are even central
to it (contrast how much wheel is mentioned in its documentation compared
to pyproject.tom). Instead I would emphasize flit itself as the bu
- Original Message -
> From: "Nick Coghlan"
> To: "Fedora Python SIG"
> Sent: Thursday, November 16, 2017 1:59:24 PM
> Subject: Re: flit
> Even though it's just a new informational link, I'm guessing we still need to
> file an FPC t
ce there are more files at [0] I'd just add that link.
>
> [0] https://src.fedoraproject.org/rpms/python-rpm-macros/tree/master
Even though it's just a new informational link, I'm guessing we still need
to file an FPC ticket for that?
> About flit:
>
> * is this wa
On 16.11.2017 08:17, Nick Coghlan wrote:
On 16 November 2017 at 16:51, Elliott Sales de Andrade
mailto:quantum.anal...@gmail.com>> wrote:
On 16 November 2017 at 01:31, Nick Coghlan mailto:ncogh...@gmail.com>> wrote:
However, if flit is now adding its own shim implcit
On 16 November 2017 at 16:51, Elliott Sales de Andrade <
quantum.anal...@gmail.com> wrote:
> On 16 November 2017 at 01:31, Nick Coghlan wrote:
>>
>> However, if flit is now adding its own shim implcitly, then the answer
>> would just be "Yes".
>>
>
On 16 November 2017 at 01:31, Nick Coghlan wrote:
> On 16 November 2017 at 12:30, Orion Poplawski wrote:
>
>> So - is it possible to build rpms with flit?
>>
>
>
There are already some packages that are built using flit:
$ dnf repoquery --disablerepo=\* --enablerepo=
On 16 November 2017 at 12:30, Orion Poplawski wrote:
> So - is it possible to build rpms with flit?
>
I haven't checked recently, but I believe flit still omits `setup.py` from
its sdists by default, and the Python RPM macros are still expecting to be
able to call that directly.
So - is it possible to build rpms with flit?
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane or...@nwra.com
Boulder, CO 80301 https://www.nwra.com
30 matches
Mail list logo
